mein Emacs kriegt eine 75 MB Textdatei, die ich gerade mal ausprobiert habe, problemlos gebacken.

meiner ist länger :p

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).

z.T. 128MB...: das ist ja Kinderkacke

z.T. 128MB...: das ist ja Kinderkacke

Es sind 256MB auf 32Bit-Systemen. Aber wer verwendet denn heutzutage noch 32Bit-Systeme?

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

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

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.

habe ich irgendwas anderes behauptet?

_matze schrieb:

Welche CPU verbaut ist, ist doch irrelevant, solange ein 32-Bit-OS eingesetzt wird.

habe ich irgendwas anderes behauptet?

Nee, eigentlich nicht.

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.

Warum kann ich nicht Dateien aufmachen die so groß wie der verfügbare Speicher sind? (abzüglich natürlich einem kleinen administrations overhead).

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!

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.

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.

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.

Dachte mir nur, dass das für Nicht-Lisper eher uninteressant ist.

Aber vielleicht besser für Shades Blutdruck

nman schrieb:

Dachte mir nur, dass das für Nicht-Lisper eher uninteressant ist.

Aber vielleicht besser für Shades Blutdruck

Hoppla, mein Kommentar war natürlich nicht als "Für Deine Frage interessiert sich niemand" gedacht, sondern mehr als "Für Entwickler und User ist das kein Problem, darum interessiert sich niemand sonderlich für diese Eigenheit".

Tut mir leid, wenn das zu pampig rüberkam.

Tut mir leid, wenn das zu pampig rüberkam.

Nein, tat es gar nicht. Ich wollte nur die technischen Hintergründe für dieses willkürlich erscheinende 256MB-Limit sind bzw. sein könnten.