Hallo zusammen.
Es geht um die CSV-Dateien, die WSPR als Monatsdaten bereit stellt.
Zur Info: WSPR = W(eak) S(ignal) P(ropagation) R(eporter)
Wer Genaueres wissen möchte:
http://wsprnet.org/drupal/
Hier wird u. a. unter 'Download' eine monatliche Liste aller
Verbindungen als *.zip eingestellt.
Ich habe folgendes Problem:
Nach dem Entpacken habe ich eine Riesen-CSV Datei mit ca. 2G
Mich interessieren ja erstmal nur meine eigenen Verbindungen.
Also selektieren. Aus den ..zig Millionen Datensätzen bleiben
für mich nur ein paar (..zig) tausend übrig.
Das nur zur Erklärung.
Zum Verarbeiten habe ich mir ein dBase/Clipper (Sorry, DOS-Mensch)
Programmm geschrieben, das die CSV-Datei einliest, und die für mich
wichtigen Datensätze selektiert. Hat geklappt; nachdem jedoch die
Dateigrösse in den letzten Jahren extrem angestiegen ist, steigt
mein Programm aus.
Ich denke, es liegt an der Dateigrösse.
Meine Idee: Das CSV-File in mehrere Teile spalten, die man ja dann
nach und nach verarbeiten könnte.
Wer hat eine, vielleicht auch andere, Idee?
73
Wilhelm
PS:
Alles läuft unter XP, bitte keinen Mecker diesbezgl.!
Ja ich weiss, ich bin noch etwas von früher ;-)
Nimm einfach eine aktuelle Programmiersprache wie java, python oder
ähnliches...ließ die daten zeilenwweise und nicht als ganzes...fertig
2gb sind wirklich eine lächerliche größe 2017 ;)
Unter Unix:
unzip -p riesig.zip | grep dk4tj > dk4tj.csv
"unzip -p" schreibt den Zip-Inhalt nach STDOUT, d.H es wird nicht
temporär eine 2GB-Datei auf die Platte geschrieben.
Das sollte auch das WinDOS unzip.exe können. Evtl. mit "unzip /p"?
"grep dk4tj" sucht daraus nur die Zeilen aus, die "dk4tj" enthalten.
-> was ähnliches bieten auch die Windows-Bordmittel. "find.exe"?
"> dk4tj.csv" schreibt alle passenden Zeilen in eine neue Datei.
Beachten: Header-Zeile fehlt, die kannst du selber leicht nachrüsten.
Das Filtern der CSV-Datei geht auch mit Windows-Bordmitteln, dazu muss
man keine *nix-Kommandozeilentools installieren.
1
findstr /c:"blabla" riesig.csv > gefiltert.csv
gibt alle in riesig.csv enthaltenen Zeilen, die "blabla" enthalten, in
gefiltert.csv aus.
Das setzt natürlich voraus, daß die interessierenden Einträge so leicht
zu identifizieren sind.
findstr kennt aber auch reguläre Ausdrücke ("regex"), so daß sich damit
auch komplexere Filterkriterien konstruieren lassen.
https://technet.microsoft.com/en-us/library/bb490907.aspx
Wilhelm S. schrieb:> Nach dem Entpacken habe ich eine Riesen-CSV Datei mit ca. 2G
Wenn du die Datei unter DOS noch vollständig entpacken kannst, kannst du
sie auch unter DOS weiter verarbeiten (im Sinne von: filtern). Das
sollte logisch ein, oder?
> Hat geklappt; nachdem jedoch die> Dateigrösse in den letzten Jahren extrem angestiegen ist, steigt> mein Programm aus.
Sehr wahrscheinlich deshalb, weil schon die Originaldatei nicht mehr
vollständig entpackt werden kann, das Ergebnis als irgendwo mittendrin
einfach aufhört, weil das DOS-Limit von 2GB Dateigröße gerissen wurde.
Es gibt also zwei Probleme:
1) Die Datei kann nicht mehr vollständig entpackt werden.
2) Dein eigenes Werk ist unfähig, mit "truncated input" korrekt
umzugehen. Gute Software(tm) würde in diesem Fall einfach eine
Fehlermeldung über eine illegale Datei-Struktur absondern, ansonsten
aber alles (bis auf die letzte nur noch teilweise ausgepackte Zeile)
korrekt verarbeiten. Du hast wohl nie gelernt, sowas zu schreiben...
> Ich denke, es liegt an der Dateigrösse.
Natürlich, die maximale Dateigröße unter DOS war schließlich zu keiner
Zeit ein Geheimnis...
> Meine Idee: Das CSV-File in mehrere Teile spalten
Das hilft dir nicht wirklich. Das Problem tritt ja bereits bei der
Erzeugung der Datei durch das Entpacken auf. Sie ist dann bereits
kaputt, weil unvollständig.
Alles, was dein Ansatz bringen könnte: Die Fehler in deinem eigenen Werk
zu umschiffen. Ich persönlich würde dann aber eher mein eigenes Werk
nachbessern. Schon aus Gründen der Programmierer-Ehre...
Blöd bloß, dass das im konkreten Fall das Problem auch nicht wirklich
lösen würde. Zwar könnte dann dein Programm wenigstens den entpackten
Teil der Datei korrekt verarbeiten, aber es würde nach wie vor die
unvollständige Zeile fehlen und auch alles, was danach noch kommt...
Als einzige Möglichkeit unter DOS würde ich hier sehen: Von
Dateiverarbeitung auf Streamverarbeitung umsteigen. Sprich: Entpacker
sagen, dass er das Ergebnis nach stdout liefern soll (statt es in einer
Datei abzulegen) und deinem eigenen Programm sagen, dass es stdin
verarbeiten soll, statt einer Datei. Für einen auch nur halbwegs
kompetenten Programmierer sind die nötigen Änderungen am Programm eine
Sache von wenigen Minuten.
An der Kommandozeile wäre der Aufruf dann in etwa so:
entpacker quelldatei <option für "entpacke nach stdout"> | deinprogramm
<option für "lies von stdin"> zieldatei
Das "|" ist der Trick. Das ist eine Pipe, der Entpacker füttert seine
Ausgabe über stdout dort hinein, dein Programm hingegen bekommt es über
stdin.
Das Schicke ist: für diese Pipe gibt es auch unter DOS keine
Beschränkungen, sie kann unendlich lang werden. 2GB-Grenze adé...
Sprich: dein nächstes Problem würde erst auftreten, wenn der Umfang des
Teils der Datei, welcher dich interessiert, die 2GB-Grenze
überschreitet. Das wirst du vermutlich aber nicht mehr erleben. Ich sehr
wahrscheinlich auch nicht...
c-hater schrieb:> Als einzige Möglichkeit unter DOS würde ich hier sehen: Von> Dateiverarbeitung auf Streamverarbeitung umsteigen. Sprich: Entpacker> sagen, dass er das Ergebnis nach stdout liefern soll (statt es in einer> Datei abzulegen) und deinem eigenen Programm sagen, dass es stdin> verarbeiten soll, statt einer Datei.
Das willst Du unter DOS hinbekommen?
Vielleicht sollte der Threadstarter etwas mehr vom tatsächlich
verwendeten Betriebssystem erzählen. Tatsächlich DOS?
Oder nicht vielleicht doch nur ein DOS-Programm, das unter einem (mäßig
aktuellen) Windows in der üblichen NTVDM läuft?
Rufus Τ. F. schrieb:> Das willst Du unter DOS hinbekommen?
Natürlich, oder siehst du da ein konzeptionelles Problem?
Ich jedenfalls sehe keins. Piping unter DOS habe ich vor vielen
Jahrzehnten schon erfolgreich benutzt. OK, ich müßte sicherlich meine
DOS-Kennntnisse ganz erheblich auffrischen, um das heute auch wieder
machen zu können, das meiste von dem Scheiß habe ich sicherlich
mittlerweile vergessen. Aber ich habe meine alte Papierdoku aus dieser
Zeit noch. D.h.: ich könnte mir das sogar auf dem Klo ooder in der
Badewanne wieder anlesen. Wenn es denn mein Problem wäre und ich deshalb
entsprechend motiviert wäre...
Ganz sicher bin ich jedenfalls, dass es keine Limitierung der Pipelänge
gab, denn schon einige der Anwendungen von damals(tm) rissen da locker
die 2GB-Grenze innerhalb von Tagen und liefen dann viele Jahre am
Stück...
> Vielleicht sollte der Threadstarter etwas mehr vom tatsächlich> verwendeten Betriebssystem erzählen. Tatsächlich DOS?
Das könnte zumindest keinesfalls schaden...
> Oder nicht vielleicht doch nur ein DOS-Programm, das unter einem (mäßig> aktuellen) Windows in der üblichen NTVDM läuft?
Würde meiner Meinung nach praktisch nix ändern. Höchstens, dass man das
2GB-DOS-Limit auf das 4GB-NT-FAT-Limit ausdehnen könnte. Aber selbst
wenn das möglich wäre, wäre es nur eine Lösung für Arme, eben für Leute,
die nicht wirklich programmieren können und immer nur das
zusammefrickeln, was sie halt können...
c-hater schrieb:> Ganz sicher bin ich jedenfalls, dass es keine Limitierung der Pipelänge> gab,
Magst Du mir erklären, wie das auf einem nicht-multitaskingfähigen
"Betriebssystem" funktionieren soll? Ist ja nicht so, daß unter DOS das
erzeugende und das empfangende Programm gleichzeitig laufen könnte -
also muss der Inhalt der Pipe irgendwo zwischengespeichert werden, und
wenn DOS eins nicht hat, dann RAM.
Rufus Τ. F. schrieb:> Vielleicht sollte der Threadstarter etwas mehr vom tatsächlich> verwendeten Betriebssystem erzählen. Tatsächlich DOS?>> Oder nicht vielleicht doch nur ein DOS-Programm, das unter einem (mäßig> aktuellen) Windows in der üblichen NTVDM läuft?
Wilhelm hat im Eingangspost bereits erwähnt, dass alles unter XP
läuft...
Tom schrieb:> dass alles unter XP läuft...
Hab' ich dann wohl übersehen, bzw. wurde von "Clipper" und DOS
überblendet.
Nun, wenn Wilhelm sich hier noch mal meldet, dann kann er ja vielleicht
mehr über die benötigte Art der Filterung seiner CSV-Datei erzählen.
Das ist ja inhaltlich etwas knapp:
Wilhelm S. schrieb:> Mich interessieren ja erstmal nur meine eigenen Verbindungen.> Also selektieren.
Eventuell genügt einer der genannten Kommandozeilenansätze (sei es mit
grep, findstr oder was auch immer).
Rufus Τ. F. schrieb:> Magst Du mir erklären, wie das auf einem nicht-multitaskingfähigen> "Betriebssystem" funktionieren soll? Ist ja nicht so, daß unter DOS das> erzeugende und das empfangende Programm gleichzeitig laufen könnte -> also muss der Inhalt der Pipe irgendwo zwischengespeichert werden, und> wenn DOS eins nicht hat, dann RAM.
Das ist eine intelligente Frage und ich muss zugeben, dass ich darauf im
Moment keine Antwort weiss. Ich kann also aktuell nicht erklären, warum
das damals so funktioniert hat, wie es funktioniert hat.
Das mit dem begrenzten RAM ist dabei noch nichtmal das Problem, einen
unendlichen FIFO kann man mit beliebig begrenztem RAM realisieren,
notfalls mit einem einzigen Byte. Aber die Tatsache, dass pures DOS kein
Multitasking-OS ist, läßt sich nicht wegdiskutieren und der beschriebene
Ansatz funktioniert nur, wenn wenn Sender und Empfänger der Pipe
parallel laufen können. D.h.: in meiner Erinnerung muss definitiv ein
wichtiger Punkt bezüglich der damaligen Umgebung fehlen. Es kann
definitiv zumindest kein pures DOS gewesen sein, soviel ist schonmal
sicher. Andererseits bin ich sehr sicher, dass ich "unter DOS"
programmiert habe.
Ich versuche, den offensichtlichen Widerspruch anhand der noch
vorhandenen Unterlagen aufzuklären...
c-hater schrieb:> Aber die Tatsache, dass pures DOS kein> Multitasking-OS ist, läßt sich nicht wegdiskutieren und der beschriebene> Ansatz funktioniert nur, wenn wenn Sender und Empfänger der Pipe> parallel laufen können.
Es wird aus einer Datei gelesen und direkt in eine andere geschrieben,
das sollte DOS gekonnt haben?
Manfred schrieb:> Es wird aus einer Datei gelesen und direkt in eine andere geschrieben
Nein, eine Pipe ist was anderes.
Es geht nicht um
1
programm1 bla.txt > fusel.txt
sondern um
1
programm1 bla.txt | programm2
Die Ausgabe von Programm1 wird durch die Pipe (|) an Programm2
übergeben.
("bla.txt" sei hier generischer Platzhalter für irgendwelche
Kommandozeilenargumente für "programm1")
In MS-DOS sind Pipes über temporäre Dateien implementiert, deswegen
nennt man sie auch Fake-Pipes
Aber der TE hat ja Windows XP, da sollte es auch echte Pipes geben. Ob
die |-Syntax in der Eingabeaufforderung diese tatsächlich nutzt, oder ob
dort aus Kompatibilitätsgründen immer noch temporäre Dateien verwendet
werden, weiß ich allerdings nicht.
Löst das die selektions Aufgabe nicht?
-
Dass beim Entpacken u.U. die resultierende Datei nach 2GB abgewürgt wird
ist doch eine Limitierung des Dateisystems. Also sollte es doch genügen
die Arbeit auf einer mit fähigem Dateisystem eingerichteter Partition zu
erledigen. Ja?
NB: dass für mit Bordmittel bewältigbare Trivialaufgaben umständlich
eigene, kaputte Programme geschrieben werden ist schon... "seltsam".
> PS:> Alles läuft unter XP, bitte keinen Mecker diesbezgl.!> Ja ich weiss, ich bin noch etwas von früher ;-)
Nein, XP (& DOS) sind für die Spätaufsteher.
Früher[TM] gab es echte Computer und echte Programmierer
Kommandozeile vor dem Frühstück für Alle! schrieb:> Wo kommen denn nun Pipes zum Einsatz?
Lies doch einfach mal das, was "c-hater" vorgeschlagen hat.
> Dass beim Entpacken u.U. die resultierende Datei nach 2GB abgewürgt wird> ist doch eine Limitierung des Dateisystems.
Genau das würde seine Lösung nämlich umgehen, vorausgesetzt, daß beide
Prozesse an den Enden der Pipe tatsächlich gleichzeitig arbeiten können.
Um es zusammenzufassen:
1
unzip monster.zip | find /i "blabla" > redux.csv
(vorausgesetzt, daß "unzip" auf diese Art und Weise aufgerufen auf
stdout ausgibt)
Hallo zusammen,
da habe ich ja eine Lawine losgetreten, oje.
Noch zur allgemeinen Info:
Alles läuft in der DOS-Box von XP. Ich bleibe bei XP, weil
man da noch einen Vollbildschirm im DOS-Fenster bekommt.
Ja, so sieht es aus:
> Timestamp Call MHz SNR Drift Grid Pwr Reporter RGrid km az> 2017-12-05 19:30 DL3NDR 0.475727 -27 0 JN59no 0.1> EA5DOM-1 IM98xn 1514 220> 2017-12-05 19:30 DH5RAE 0.475766 -12 0 JN68qv 0.5> EA5DOM-1 IM98xn 1571 228
Datum und Zeit liegen jedoch im Unix-Format als ein Item vor und
müssen noch entsprechend aufgebröselt werden; das ist aber kein
Problem.
Die Lösung ist 'Find' mit Umleitung in eine andere Datei.
Von da komme ich schon weiter.
Das *.zip-File wird ordentlich entpackt -> ca. 2,4G
'Find' hat dann auch nicht gemeckert, das Suchen hat aber einige
Zeit gebraucht. Macht nix, als 'Rentier' habe ich ja Zeit genug.
Bzgl. Programmieren:
Ich bin zwar kein Profi, aber auch als Laie kann man ordentliche
Arbeit abliefern. Für meine Apotheke habe ich in dBase/Clipper
vor Jahren eine Anwendung geschrieben, die das Wichtigste für
den Apothekenalltag erledigte, nämlich in einer Liste nachsehen zu
können und Rezepte zu bedrucken. Mit diesem Programm ist 7 Jahre ohne
Fehler und Mecker Geld verdient worden. Es waren am Schluss
fast 400.000 Datensätze. Ca. 250.000 Zeichen Quellcode.
Also so ganz unbedarft bin ich nicht. Was andere mit Excel erledigen,
mache ich heute noch mit dBase im Handbetrieb. Geht auch.
Ich danke euch allen für eure Tips; mein Problem ist damit gelöst.
73
Wilhelm
PS:
@C-Hater
Ist dein Name Programm?
Wilhelm S. schrieb:> Hallo zusammen,>> da habe ich ja eine Lawine losgetreten, oje.
Nicht doch, dies ist ein harmloser Verlauf.
Nicht zuletzt dank Deiner gleich im Eröffnungspost ziemlich umfassenden
Beschreibung. Schlicht mustergültig.
> Die Lösung ist 'Find' mit Umleitung in eine andere Datei.> Von da komme ich schon weiter.> Das *.zip-File wird ordentlich entpackt -> ca. 2,4G> 'Find' hat dann auch nicht gemeckert, das Suchen hat aber einige> Zeit gebraucht.
Do schau her, von wegen Tamtam um Pipes... :-)
> Bzgl. Programmieren:> Ich bin zwar kein Profi, aber
Ich gratuliere!
Es freut mich sehr hie und da auch unter Anwendern welchen zu begegnen,
die EDV als "El. Datenverarbeitung" begreifen UND umsetzen - entgegen
dem Volkstrend "Ende Der Vernunft" welcher leider auch unter Profis
grassiert!
- - -
> Noch zur allgemeinen Info:> Alles läuft in der DOS-Box von XP. Ich bleibe bei XP, weil> man da noch einen Vollbildschirm im DOS-Fenster bekommt.
Wenn Du "so Einer" bist, lass Dir empfehlen in bash & GNU-tools zu
schnuppern. M.M.n. wird es Dir gefallen.
Migrationsstrategie:
- erstmal unter XP mit CygWin starten (mit bloß dem Grundstock an core
Pakete)
- danach doch auf ein Linuxsystem wechseln (Zweitrechner m. *buntu),
Terminal und/oder per [strg][alt][Fx] die Textkonsole nutzen.
Bei "Heimweh" einfach das Paket dosbox einrichten: damit dürften auch
die alten dBase/Clipper unter Linux laufen (meine Einschätzung vom
Schiff aus, hab keine eigene handfeste Erfahrung mit dosbox)
Ja, etwas Umgewöhnunsaufwand ist zu leisten.
Mein Bauchgefühl gibt mir die Überzeugung dass dies VIEL Potential hat
Dir zu gefallen; jedenfalls besser als irgendein Krampf per "modernem"
WindowsXY.
Wilhelm S. schrieb:> Noch zur allgemeinen Info:> Alles läuft in der DOS-Box von XP. Ich bleibe bei XP, weil> man da noch einen Vollbildschirm im DOS-Fenster bekommt.
Dann probier mal folgendes: Lösung für Win7 (und wahrscheinlich auch
höher):
Win+R drücken -> im Fenster 'Ausführen' "cmd" eingeben -> Enter
Rechtsklick auf die obere 'Rahmenleiste' (in der sich auch das Kreuz zum
Schliessen befindet) -> 'Eigenschaften' anklicken
Reiter Schriftart bzw Reiter Layout: Werte anpassen... vielleicht
hilft's Dir ja irgendwie... ;-)
Meine Einstellungen:
Bildschirm-Auflösung: 1600 x 1200
Eigenschaften v. cmd.exe:
Layout
Fenstergrösse: Breite = 130 & Höhe = 68
Schriftart
Grösse = 12 x 16
Kommandozeile vor dem Frühstück für Alle! schrieb:> Wenn Du "so Einer" bist, lass Dir empfehlen in bash & GNU-tools zu> schnuppern. M.M.n. wird es Dir gefallen.
Ist mir genauso gegangen, bin seit Jahren Linux-Fan, am liebsten auf der
Konsole. Habe aber manchmal noch ein W2k und ein WXP in der VM laufen.
Auch auf SBC bin ich jetzt "angesprungen", z.B. RaspberryPi bzw. noch
lieber OrangePi. Meine Lieblingssprache ist jetzt Python.
Falls Du bei Windows bleiben willst und eine vernünftige Konsole
brauchst, probier mal ConEmu, die kann u.a. auch die schönen alten
ANSI-Sequenzen (jaja ich weiss, W10 kann die auch wieder, aber wer will
schon W10, wenn er Linux hat).
$ ## das Zeichenmuster wonach mit grep selektiert wurde,
87
$ ## erfasst Zeilen welche irgendwie "DK4tj" (bel.Gr./Kl.Schreibung) enthalten!
88
$ ## ALSO AUCH Z.B. "DK4tja", "DK4tj6", "DK4tj/P", uvm.
89
$ ## Das ist ggfs. zu verschaerfen! --> Man lerne Mustersuche mit grep!
90
$
91
$
92
$ ## und wieviele Eintraege nennen nun Wilhelm? Was dauert das Zaehlen?
93
$ time wc -l wsprspots-20*DK4tj.csv
94
0 wsprspots-2008-04_DK4tj.csv
95
3653 wsprspots-2012-07_DK4tj.csv
96
21151 wsprspots-2016-01_DK4tj.csv
97
32529 wsprspots-2017-10_DK4tj.csv
98
57333 total
99
100
real 0m0.010s
101
user 0m0.000s
102
sys 0m0.004s
103
$
104
$ ## wow: innert 10ms wurden knapp 60k Zeilen in 4 Dateien mit "DK4tj" gezaehlt!
105
$
106
$
107
$ ## Die Maschine hier: ein betagter Laptop HP 6730b, rund 10 J. alt.
108
$ ## Details
109
$ cat /proc/cpuinfo | grep -i intel
110
vendor_id : GenuineIntel
111
model name : Intel(R) Core(TM)2 Duo CPU P8800 @ 2.66GHz
112
vendor_id : GenuineIntel
113
model name : Intel(R) Core(TM)2 Duo CPU P8800 @ 2.66GHz
114
$
115
$ cat /proc/meminfo | grep -i ^Mem
116
MemTotal: 3944540 kB
117
MemFree: 492944 kB
118
MemAvailable: 1488728 kB
119
$
120
$ ## NB:
121
$ ## das aktuell genutze Arbeitsverzeichnis ($PWD) liegt quer durch's LAN auf dem anderen Rechner,
122
$ ## ist hier per sshfs eingebunden. Auf der HD d. Laptops hier ist das System installiert.
123
$ ## KEINE SSD-Tricks.
124
$
Der Vorteil: ausser des Diskplatzes fuer die geholten Datenarchive und
die wenigen extrahierten Datensaetze welche konkret interessieren wurde
dank Pipes kein weiterer Diskplatz verwendet.
Der Nachteil: das geht mit aus dem Ärmel geschuettelten Befehle
dermassen schnell, dass jedes 'Rentier' in Stress kommt! Nix mer mit hab
ja Zeit
;-)
73 de Stephan HB9ocq
Noch ein Hinweis fuer die Interpretation der mit time ermittelten
Zeiten.
Von oben genommen:
1
:
2
real 0m7.353s
3
user 0m9.164s
4
sys 0m0.548s
5
:
Diese Maschine hat ein C2D Prozessor (Core2Duo), also 2 Physische
Rechenkerne mit je HT (Hyperthreading) Faehigkeit was unter optimalen
Umstaende auf 4 Kerne rauskommt.
real zeigt die "an der Wanduhr" verstrichene Zeit bis der Befehl durch
ist
user zeigt die Zeit welche Prozesse im Namen d. Users werkelten, vulgo
Numbercrunchingsystem zeigt die Zeit welche mit Systemaufrufe verbracht wurde, hier
typ. Dateioperationen
F: Warum ist nun user groesser als real (Wanduhrzeit)? Das kann doch
gar nicht sein, oder?
A: In der Zeit als Die "Wanduhrzeit" verstrich, wurden auf diversen
Kerne Arbeiten gleichzeitig parallel abgearbeitet. Voila!
73 de Stephan HB9ocq
> Dann probier mal folgendes: Lösung für Win7 (und wahrscheinlich auch> höher):
Stimmt zwar, aber das bringt noch nicht bash + GNU-tools daher.
(das zeigt nur in grösser wie eingeschränkt/mangelhaft CMD.EXE ist)
Mit "wahrscheinlich auch" liegst richtig: es sind solche "nebensächliche
Kleinigkeiten" welche von Win- zu Win-Varianten vom Hersteller allzuoft
und unnötigerweise verändert werden. Solches vergrault einem die Lust
am Umsteigen jedes verdammte Mal !! (bei mir letztlich zum
Totalboykott)
Nix gegen Neues und Änderungen: aber bitte im Kernbereich meiner
Aufgaben UND mit deutlich ergiebigen Vorteilen.
Nicht bei Pillepallekram der zu Stolpersteine/Ostersuche/Zeitfresser
mutiert; das hat einfach wie gewohnt zu funktionieren.
(nein, ich werde nicht Müde auf solchem herumzureiten)
c-hater schrieb:> Ich versuche, den offensichtlichen Widerspruch anhand der noch> vorhandenen Unterlagen aufzuklären...
Ich bin fündig geworden. Die Sache lief damals unter "Novell-DOS". Eine
Art Multitasker-Aufsatz für MSDOS. War wohl sowas wie ein kastriertes
Abfallprodukt der Novell "Netware"-Entwicklung für den kleinen
Geldbeutel.
Features: Keinerlei Netzwerk-Funktionalität, aber preemptives
Multitasking für DOS-Prozesse und relativ unkomplizierte Nutzung von
Speicher jenseits der damaligen DOS-Grenzen (ohne manuelle
Konfigurationsorgien in config.sys und autoexec.bat.)
Und, im Kontext dieses Threads, das Wesentliche: Tatsächlich echte
Pipes...
Danke für die sachliche und fundierte Rückmeldung.
Verschiedene dieser DOS-Multitasker hab' ich mir auch mal angesehen, es
wurde dann für ein Projekt dann doch Windows 3.0 (auf einem 386). Das
hatte den Vorteil der netten graphischen Oberfläche und schon damals
recht weiten Unterstützung für Bildschirmtreiber.
In meinem Fall musste eh' nur eine DOS-Task parallel zu einem
Windows-Programm laufen, und die Kommunikation zwischen der DOS-Task und
dem Windows-Programm lief über einen DOS-Devicetreiber (so ziemlich dem
einzigen x86-Assemblerprogramm, das ich jemals geschrieben habe).
Immerhin, der Kram(pf) funktionierte.
Gott, was bin ich froh, das alles hinter mir zu haben.
Aber ich schweife ab ...
Ob dies nun ein Memory-Hog ist beim durchstoebern von monströs grossen
Ziparchive habe ich genausowenig überprueft wie ob es in Pipe-losen
Umgebungen funktioniert (habe keine).
Ich setzte blind auf Python: das gibt es auch fuer alte Windowsen und
die verwendeten Module sys zipfile und re gibt es alle seit Py2 also
duerften da keine Hindernisse im Wege stehen.
Hier bei mir gezeugt und vollzogen unter Py2.7 auf Lubuntu 16.04.3 LTS.
Python3 will diesen Code allerdings nicht: irgendwas mit
"reo.search(..)" passt ihm nicht. Ich mag dem jetzt nicht nachgehen, man
verzeihe mir.
1
$
2
$ time ./selectCallFromWSPRNET.py wsprspots-2008-04.csv.zip DK4tj > wsprspots-2008-04_DK4tj.py.csv
3
4
real 0m1.372s
5
user 0m1.152s
6
sys 0m0.004s
7
$ time ./selectCallFromWSPRNET.py wsprspots-2012-07.csv.zip DK4tj > wsprspots-2012-07_DK4tj.py.csv
8
9
real 0m7.623s
10
user 0m7.424s
11
sys 0m0.036s
12
$ time ./selectCallFromWSPRNET.py wsprspots-2016-01.csv.zip DK4tj > wsprspots-2016-01_DK4tj.py.csv
13
14
real 0m37.233s
15
user 0m36.392s
16
sys 0m0.236s
17
$ time ./selectCallFromWSPRNET.py wsprspots-2017-10.csv.zip DK4tj > wsprspots-2017-10_DK4tj.py.csv
18
19
real 1m45.992s
20
user 1m43.948s
21
sys 0m0.556s
22
$
Die Ergebnisdateien sind md5sum nach bitidentisch mit denen oben per
shell erzeugten.
Vergleicht man die Laufzeiten, sieht man dass ein guter
S(c)h(n)ellschuss durchaus Geschwindigkeitsvorteile haben kann -
"komplexe" Pipes hin oder her.
Es darf sich gerne jeder sportlich herausgefordert fuehlen, das kurze
Pythonscript weiter zu beschleunigen oder Loesungen in anderen Sprachen
ins Rennen zu schicken (diese sollten aber ebenfalls "auf einen
Bierdeckel passen").
73 de Stephan
usuru schrieb:> ANSI-Sequenzen (jaja ich weiss, W10 kann die auch wieder, aber wer will> schon W10, wenn er Linux hat).
Da Windows10 inzwischen auch Linux kann, zumindest auf der
Kommandozeile, müsste der Spruch eher umgekehrt lauten.
Oliver
Oliver S. schrieb:> usuru schrieb:>> ANSI-Sequenzen (jaja ich weiss, W10 kann die auch wieder, aber wer will>> schon W10, wenn er Linux hat).>> Da Windows10 inzwischen auch Linux kann, zumindest auf der> Kommandozeile, müsste der Spruch eher umgekehrt lauten.>> Oliver
[ ] Bravo!
Kaufst wohl auch 'ne ganze Zaunfabrik, um allen zu mehr Freiheit zu
verhelfen...
Thread beobachten
Seitenaufteilung abschalten