[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Frunge] Brechprogramm
From: |
Dennis Heidsiek |
Subject: |
Re: [Frunge] Brechprogramm |
Date: |
Wed, 23 Sep 2009 02:02:45 +0200 |
User-agent: |
Thunderbird 2.0.0.23 (Windows/20090812) |
Hallo allerſeits,
Martin Roppelt ſchrieb am 22.09.2009 05:16 Uhr:
OK, schön, ich habe auch mal mit Java programmiert. Nimm es also ruhig.¹
Wie bereits geſagt, fühle ich mich in Java halt ſehr wohl. Ich beſtreite
aber nicht, daſs für andere Perſonen andere Sprachen beſſer geeignet
ſein mögen – da bin ich wesentlich weniger miſſionariſch als bei Neo ;-).
Aber dann sollte es auch mit einer annehmbaren Geschwindigkeit brechen.
Wenn ich für 1 KB 1 Minute warten müsste, wäre mir das zu lang … ;)
Kann ich gut nachvollziehen, das würde mir auch ganz entſchieden auf den
Wecker gehen. Aber da bin ich wie geſagt etwas optimiſtiſcher … bſpw.
braucht mein Java-Programm eine Sekunde, um die UnicodeData.txt (1.091
KB) einzuleſen und daraus die unicode.module (1.716 KB) zu generieren
(1.114.428.719 Nanoſekunden auf einem Intel Celeron 430 @1.8 GHz, um
›etwas‹ ;-) genauer zu ſein). Da ſehe ich jetzt nicht wirklich
Optimierungsbedarf.
Alſo ſollte man auch ein Bruchprogramm in akzeptabler Geſchwindigkeit
hinkriegen können :-).
Allerdings ist Java selbst ziemlich speicherfressend (auf meiner Festplatte)
(?),
Man braucht tatſächlich erſt eine Java-Laufzeitumgebung (JRE), um
Java-Programme ablaufen zu laſſen. Unter Windows muſs ſich man ſich
dafür knapp 16 MB herunterladen, unter Linux (sudo apt-get install
openjdk-6-jre bei Debian) ſollte das ähnlich ſein. Ob das jetzt
beſonders viel oder beſonders wenig iſt, kommt wohl auf den
Vergleichsmaßſtab an … die Komplettinſtallation von MiKTeX belegt 1,33
GB auf meiner Feſtplatte, ſo geſehen iſt es alſo geradezu ein ſchlankes
Programm ;-).
man kann doch auch direkt Programmdateien daraus erzeugen, stimmt das? (Sind
die dann auch entsprechend groß?). Die Objekt-Datei(en) für das Bruchprogramm
wären aber bestimmt nicht allzu groß?
Bei Java entſprechen .class Dateien wohl am eheſten Objekt-Dateien, und
ſie ſind im allgemeinen tatſächlich nicht ſehr groß. Zudem werden
mehrere davon üblicherweiſe komprimiert als jar (das iſt praktiſch
geſehen eine zip-Datei) ausgeliefert. Richtig groß werden jar-Dateien
eigentlich erſt, wenn entſprechend ſpreicherfreſſende Reſſourcen
(jpeg-Bilder, …) hinzugefügt werden.
Anſonſten enthält die GCC (GNU Compiler Collection) tatſächlich auch
einen Compiler für Java (gcj); praktiſch geſehen ſind die davon
produzierten ausführbaren Programme aber ungefähr gleich ſchnell und
gleich groß wie jar-Dateien (ſogar wesentlich größer, wenn es eine GUI
enthält und das ganze ›Toolkit‹ eingebettet werden ſoll). Zudem ſind ſie
– im Gegenſatz zu jar-Dateien – dann nicht mehr unter Windows oder Apple
ausführbar, weshalb in der Praxis eher ſelten auf dieſen Weg
zurückgegriffern wird.
Zudem man auch jar-Dateien noch einmal ordentlich verkleinern (und auch
verſchnellern) kann:
http://de.wikipedia.org/wiki/Proguard
So viel Programmlogik ist dafür bestimmt nicht nötig, eher eine gute Datenbank?
Sehr gute Frage! Das Problem bei einem primär Datenbank-baſiertem
Programm wäre wohl, daſs dieſe erſtmal erſtellt bzw. gepfegt werden
müſſte … weshalb ich da derzeitig eher zu einer Umſetzung der ſ/s (und
Ligatur-Regeln) in Programmlogik tendiere. So gibt es bereits eine freie
Umſetzung des TeX-Silbentrennungsalgorithmus in Java; wenn man den mit
den überarbeiteten (freien) Trennmuſtern füttert, ſollte man eigentlich
ſchon eine recht gute Baſis haben (Schlussstrich -> Schluss-strich →
Schluſsſtrich bzw. Sluſsſtri). Wenn man dann noch eine
Ausnahmebehandlung für ſſ (aſ-ſe, iſ-ſe, üſ-ſe, aſ-ſt, uſ-ſt, eſ-ſor, …)
hinzufügt, ſollte das eigentlich ſchon recht brauchbare Ergebniſſe liefern.
Obwohl … noch viel beſſer wäre es wohl, erſtmal den TeX-Algorihmus um
Hauptwort-Trennſtellen zu erweitern.
Aber wo wir grade dabei ſind: Gibt es irgendwo einen längeren,
einigermaßen aktuellen Text in garantiert korrekter Frakturſchreiweiſe
(etwa das Grundgeſetz)? Das wäre ein recht guter Teſtfall –
›antiquieren‹ und anſchließendes brechen ſollte wieder den Originaltext
ergeben.
¹Java und C sind ziemlich ähnlich, also?² …
²War nur’n Scherz³ ;)
Ich erinnere mich noch an Borland C unter MSDOS, da konnte man noch ſo
etwas wie
for(int i=0; i>0, i++) ARBEITSSPEICHER[i] = 0;
machen … dieſes kleine Progrämmchen hat mir noch unter Win95 äußerſt
zuverläſſig einen BlueScreen produziert ;-).
³Am liebsten wäre mir natürlich ein Shell-Programm; danach käme eine
Skript-Sprache.
Das traue ich mir leider nicht zu :-(.
PS: So was wäre echt nützlich, dann könnte ich meine E-Mail hier mit einem
Aufruf von ‚blacken --only-ſ /tmp/mutt-arch-1000-14373-258‘ brechen.
Weck’ bloß nicht meinen Ehrgeiz ;-).
Viele Grüße,
Dennis-ſ
- Re: [Frunge] Fraktur-Panagramm/UNZ, (continued)
- Re: [Frunge] Fraktur-Panagramm/UNZ, Dennis Heidsiek, 2009/09/20
- Brechprogramm (was: Re: [Frunge] Fraktur-Panagramm/UNZ), Dennis Heidsiek, 2009/09/20
- [Frunge] Re: Brechprogramm, Arno Trautmann, 2009/09/21
- Re: [Frunge] Re: Brechprogramm, Dennis Heidsiek, 2009/09/21
- Re: [Frunge] Re: Brechprogramm, Martin Roppelt, 2009/09/21
- Re: [Frunge] Re: Brechprogramm, Dennis Heidsiek, 2009/09/21
- Re: [Frunge] Re: Brechprogramm, Martin Roppelt, 2009/09/21
- Re: [Frunge] Re: Brechprogramm, Dennis Heidsiek, 2009/09/21
- Re: [Frunge] Re: Brechprogramm, Dennis Heidsiek, 2009/09/21
- Re: [Frunge] Brechprogramm, Martin Roppelt, 2009/09/21
- Re: [Frunge] Brechprogramm,
Dennis Heidsiek <=
- Re: [Frunge] Brechprogramm, Martin Roppelt, 2009/09/22
- Re: [Frunge] Brechprogramm, Arno Trautmann, 2009/09/23
- Re: [Frunge] Brechprogramm, Martin Roppelt, 2009/09/23
- Re: [Frunge] Brechprogramm, Arno Trautmann, 2009/09/23
- Lua (was: Re: [Frunge] Brechprogramm), Dennis Heidsiek, 2009/09/25
- Re: [Frunge] Lua, Martin Roppelt, 2009/09/25
- Re: [Frunge] Brechprogramm, Dennis Heidsiek, 2009/09/25
- Re: [Frunge] Brechprogramm, Christian Kluge, 2009/09/23
- Re: [Frunge] Brechprogramm, Arno Trautmann, 2009/09/23
- Re: [Frunge] Brechprogramm, Christian Kluge, 2009/09/23