Große Dateien editieren, womit?

[wilfried]

Hallo

womit edititert ihr große Dateien (>20MB)?
AE.EXE ist schnarchlangsam beim Öffnen.
Mein Lieblingseditor SPFPC bekommt so eine Datei erst gar nicht geöffnet.

[Andi B.]

VisualSlickEdit 4.0

[aschn]

Dateien bis 53 MB kann man sogar noch mit EPM bearbeiten. Sonst müsste auch Qedit gehen: http://trac.netlabs.org/qtapps/wiki/QT4%20Office

[wilfried]

EPM schafft es hier leider auch nicht und VisualSlickEdit gibt es ja nicht mehr. Dann probiere ich mal Qedit.

[Markus]

EPM schafft es hier leider auch nicht und VisualSlickEdit gibt es ja nicht mehr. Dann probiere ich mal Qedit.

Auf Hobbes gibt es ein Update auf 4.0b. Falls du ein SlickEdit hast kannst du ja mal das probieren.

Noch was wäre eventuell Vim oder auch auf Hobbes.
Mit Vim habe ich noch nicht gearbeitet. K. A. ob das Programm nutzbar ist.

[wilfried]

Nach dem Öffnen der gewünschten Datei teilt mir Qedit folgendes mit:

<dies kann man wohl vernachlässigen>
XmlMigration::run - could not find old file F:/home/default/.qedit.db. Aborted.

<während es hier wohl um Speicherallokation geht!?>
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc

Killed by SIGABRT
pid=0x0160 ppid=0x002c tid=0x0001 slot=0x0124 pri=0x0200 mc=0x0001
G:\temp\install\qedit\qedit.exe
Process dumping was disabled, use DUMPPORC / PROCDUMP to enable it.

Weitere Vorschläge?

[wilfried]

Auf Hobbes gibt es ein Update auf 4.0b. Falls du ein SlickEdit hast kannst du ja mal das probieren.

Das habe ich auch schon gefunden, aber leider habe ich VisualSlickEdit nicht.

[Holger]

Hallo Wilfried

kommt auch ein wenig darauf an, was Du machen willst.
Als "Einfachstversion" geht z.B. der Editor von FileCommander/2.
Öffnet bei mir 48 MB in ca. 3 sec.

[aschn]

Noch was wäre eventuell Vim

Vim geht natürlich, genau so wie Emacs. Beide schalten bei großen Dateien (genau so wie SlickEdit) auf teilweises Laden um. Es gibt da auch noch neben Vim ein paar Befehlszeileneditoren, die das auch können.

MED und jedit können das auch nicht. Dass Qedit nicht geht, hätte ich nicht gedacht, weil es AFAIR eine vereinfachte Version von Kate sein soll, wobei ich mir jetzt nicht mehr so sicher bin.

Die OS/2-Version von Eclipse könnte das vielleicht, aber beherrscht anscheinend nicht das Teilweise-Öffnen. Das Laden dauert sehr lange und danach endet dann der Prozess mit einer Meldung "Out of memory", die nach Bestätigung auch meine Mozille schließt - Shared Memory also.

[andreas]

ich finde den Editor ME Martins Editor ziemlich gut.
einfach, vielseitig, schnell und für große dateien geeignet.
besonders gut finde ich, dass man zwischen verschiedenen formaten bequem hin-
und herschalten kann.
man kann (und sollte) ihn auch individuell konfigurieren (geeignet für
fast alle gewohnheiten)

[wilfried]

Hallo Holger,

Als "Einfachstversion" geht z.B. der Editor von FileCommander/2.
Öffnet bei mir 48 MB in ca. 3 sec.

tatsächlich die Datei (62MB) öffnet FC in unter 10 sec. Nun muss ich auf meine alten Tage doch noch zum NC-Look-and-Feel-Fan werden ?!

[wilfried]

Hallo Andreas,

ich finde den Editor ME Martins Editor ziemlich gut.
einfach, vielseitig, schnell und für große dateien geeignet.
besonders gut finde ich, dass man zwischen verschiedenen formaten bequem hin-
und herschalten kann.
man kann (und sollte) ihn auch individuell konfigurieren (geeignet für
fast alle gewohnheiten)

ME kämpft hier genauso hart wie AE, beim Laden.

[LutzG]

Nun muss ich auf meine alten Tage doch noch zum NC-Look-and-Feel-Fan werden ?!

Bin seit über 40 Jahren Fan von NU und NC ...

... und es gab doch auch mal die Graham-Utilities...?

Gruß
Lutz

BTW: mein häufigstes Arbeitsmittel ist FC/2 ...

[wilfried]

Aktueller Stand zu diesem Thema:
Um meinen Lieblingseditor weiter nutzen zu können, habe ich mir einen "BIG FILE SPLITTER" gebaut.
Damit zerlege ich grosse Dateien (aktuell > 1GB) in Segmente zu 1 Mio. Zeilen.
Ich meine CR+LF-Dateien.
Aktuell geht es nur um "Reingucken", aber vielleicht baue ich noch etwas um die Segmente wieder zusammen zusetzen, wenn Änderungen erforderlich sind..
Das ist übrigens ein "überschaubares" REXX-Projekt. Unnötigerweise habe ich das mit Vispro/REXX realisiert.
Falls Interesse besteht können wir das auf dem Usertreffen in Köln thematisieren.

Und wenn mir jemand den Tag "versauen" möchte, sind Hinweise auf existierende Tools gleicher Art willkommen.

[aschn]

Als "Einfachstversion" geht z.B. der Editor von FileCommander/2.
Öffnet bei mir 48 MB in ca. 3 sec.

tatsächlich die Datei (62MB) öffnet FC in unter 10 sec.

1 Datei mit 53 MB (Obergrenze) schafft sogar der EPM noch - in ca. 1 s einschließlich Keyword Highlighting und das ist PM, kein VIO.

Unter "großen Dateien" versteht man heute etwas ganz anderes.

[Frank Wochatz]

Darf ich mal fragen, was das für Textdateien sind? Ich meine 50MB, 60MB, und sogar >1GB (!) Text, da fällt mir kein Beispiel ein. Bzw. wie wärs die Daten auf mehrere Files zu verteilen?

[wilfried]

In diesem Fall ist es eine Log-Datei. Eine selbstgebaute Debug-Hilfe in der alle SQL-Zugriffe eines DB2-Testlaufs festgehalten werden.

Code: Alles auswählen

14.07.15 15.11    1.382.524 K      0 a---  SQL.LOG
14.07.15 15.15    106.212.190      0 a---  SQL1.LOG
14.07.15 15.15    112.385.090      0 a---  SQL2.LOG
14.07.15 15.16    112.385.090      0 a---  SQL3.LOG
14.07.15 15.16    112.807.887      0 a---  SQL4.LOG
14.07.15 15.16    112.862.039      0 a---  SQL5.LOG
14.07.15 15.16    112.862.039      0 a---  SQL6.LOG
14.07.15 15.17    112.862.039      0 a---  SQL7.LOG
14.07.15 15.17    112.862.039      0 a---  SQL8.LOG
14.07.15 15.17    112.862.039      0 a---  SQL9.LOG
14.07.15 15.17    112.862.190      0 a---  SQLA.LOG
14.07.15 15.17    112.862.038      0 a---  SQLB.LOG
14.07.15 15.18    112.862.038      0 a---  SQLC.LOG
14.07.15 15.18     35.837.427      0 a---  SQLD.LOG
14.07.15 15.18              0      0 ----  SQLE.LOG
14.07.15 15.18              0      0 ----  SQLF.LOG
14.07.15 15.18              0      0 ----  SQLG.LOG
14.07.15 15.18              0      0 ----  SQLH.LOG
14.07.15 15.18              0      0 ----  SQLI.LOG
14.07.15 15.18              0      0 ----  SQLJ.LOG
14.07.15 15.18              0      0 ----  SQLK.LOG
14.07.15 15.18              0      0 ----  SQLL.LOG
        xx Datei(en) 2.903.235 K Byte belegt
                    21.728.968 K Byte frei

Zu Beginn dieses Threads ging es um diese Dateien.

Code: Alles auswählen

19.01.14 10.08     65.193.390    390 a---  geolitecity-blocks.csv
19.01.14 10.10     26.918.333    392 a---  geolitecity-location.csv
         2 Datei(en)  92.111.723 Byte belegt
                    21.729.468 K Byte frei

In diesen Dateien sind die Lokationsdaten für IP-Adressen hinterlegt. Auf Basis dieser Daten werte ich den Access-Log meiner Webseiten aus.

[Andi B.]

Meine größten log Dateien sind die des Weasel Mail Servers mit bis zu mehreren 100MB. Wenn MED die nicht mehr schafft, dann nehme ich VisualSlickEdit. Wenn ich mich recht erinnere, kann auch KON mit größeren Dateien umgehen. Bei 2GB ist allerdings bei jedem mir bekannten OS/2 Editor Schluss.

Da fällt mir ein, eFTE könnte gehen. Zumindest arbeitet Gregg an dem und könnte auch >2GB Support einbauen.

[wilfried]

Hallo Andi,

bei mir geht es darum mit SPFPC für OS/2 weiter arbeiten zu können. Vom TSO her bin ich an diesen Editor gewöhnt und habe auch einige Erweiterungen dafür gebaut.

Ich habe festgestellt das es mit SPFPC Probleme gibt, wenn die Eingabe mehr als 1 Million Zeilen hat.
Durch den "Big File Splitter" kann ich festlegen wieviel Zeilen je Segment zu speichern sind und damit habe ich eine akzeptable Umgehung meines Problems.

Ich suche also nicht mehr nach Alternativen, sondern wollte hier nur berichten welche Lösung für mich funktioniert.
Was allerdings passiert wenn die erste Datei >2GB auftaucht, warte ich erstmal ab.

[Frank Wochatz]

Hi Wilf, ev kann man ja so ein Logfile auch mal sichern und ein frisches neues anfangen. Wenn ich es richtig im Kopf habe werden meinen Weblogs täglich oder wöchentlich neu geschrieben, müsste nachsehen. Das Problem ist ja nicht nur der Editor, ich denke dass mit diesen Files mit Rexx zu arbeiten auch ganz schön langsam wird.

[Andi B.]

Hi Wilfried,
es ist ja super, dass es bei unserem OS noch immer sehr viele verschiedene Möglichkeiten gibt ein Problem zu lösen. Oder zumindest jeder einen akzeptablen work around dafür findet. Und wenn sich jemand hinsetzt und ein eigenes Tool dafür schreibt welches dann seinen ganz speziellen Bedürfnissen entspricht, umso besser. Also lass dir nicht den Tag versauen wenn noch andere Wege vorgeschlagen werden und programmiere ruhig weiter an den Tools die sinnvoll sind für dich.

Ich wollte nur der Vollständigkeit halber auch andere Lösungsmöglichkeiten in die Diskussion werfen. Auch Franks Posting bez. regelmäßig log Files wegsichern und neu starten passt da für mich. Wenn das entsprechende Programm eine solche Funktion unterstützt, super. Ich meine ZOC kann das. Also log file name aus dem aktuellem Datum generieren. Bei vielen Programmen muss man das allerdings händisch regelmäßig neues log starten.

Btw. wenn jemand den meiner Meinung nach noch immer besten und umfangreichsten Editor für Programmierer haben will, dann wird er auch einen Weg finden den zu bekommen. VisualSlickEdit für OS/2 ist sowas von obsolet und die Herstellerfirma schert sich seit vielen Jahren aber sowas von überhaupt nichts um Kundenanfragen, die kümmert es sicherlich wenig wenn irgendwo noch jemand auf einem OS/2 Rechner eine Kopie laufen hat. Nur wer VS nicht kennt, es ist wirklich ein Editor für Programmierer. Mit mächtig vielen Funktionen in den Tiefen der Einstellungen verborgen. Nicht unbedingt für jemanden was der ab und an was editieren will, sondern Programmierer die sich auch die Zeit nehmen die entsprechenden Funktionen zu nutzen. Oder solche die eben von VS für Win gewisse Funktionen gewohnt sind in diese unter OS/2 nicht missen wollen. Obwohl man VS v4.0 doch schon sein Alter ansieht. Unter Win gibt's schon >11....

[wilfried]

Hi Wilf, ev kann man ja so ein Logfile auch mal sichern und ein frisches neues anfangen.

Hallo Frank,
zur Klarstellung, das ist das Logfile aus EINEM Testlauf!

[wilfried]

Das Problem ist ja nicht nur der Editor, ich denke dass mit diesen Files mit Rexx zu arbeiten auch ganz schön langsam wird.

Ich habe es gerade nochmal laufen lassen. Dauert keine drei Minuten bis die Eingabe zerlegt ist.

[Frank Wochatz]

das ist das Logfile aus EINEM Testlauf!

Wow. Oder besser: OMG.

[LotharS]

zur Klarstellung, das ist das Logfile aus EINEM Testlauf!

Bevor ich wie gewohnt mit dem Spruch "small is beautiful" nerve : Keine Ahnung, aber vielleicht ließe sich dafür etwas von PMMail abkupfern: die lassen ihr Logfile bis zu einer (sogar einstellbaren) Größe anschwellen, benennen es dann um in ein historisches und beginnen ein frisches... Fiele in der Performance - im Vergleich zu den DB-Zugriffen - wahrscheinlich gar nicht weiter auf, dann aber bestimmt hinterher beim Studieren des Logs