Re: [Steak-developer] Re: steak

[Erik S. <esi...@es...>]

Hallo,

ergänzend zu Razi's Überlegungen bez. *Datenbank* möchte ich
erwähnen, dass bei CPAN ein optionales Package namens 
"DBFile" downloadbar ist. Zusammen mit "DBFile::Lock" (Record-
File Locking) basiert es auf der BerkeleyDB und damit ist es
prinzipiell möglich auch von C/C++ auf die "Datenbank" zugreifen
zu können "DBFile" ist recht performant, kommt auch mit grossen
Datenmengen gut zurecht, und die Lernkurve strebt gegen Null.

Dennoch muss ich auch Razi's Bedenken teilen, dass man nicht
unbedingt Perl, nebst richtiger Version und allen notwendigen
Packages, die Vorraussetzung einer *Steak* Installation sein
sollte. Von daher sollte man noch einmal Nachdenken, ob 
Perl wirklich eingesetzt werden sollte.

MfG
-Sittmann Erik




On Fri, 6 Sep 2002 22:58:04 +0200
Razi Lotfi-Tabrizi <raz...@we...> wrote:

> Hi Jörg,
> 
> ich will mit dieser Email drei Deiner Emails gleichzeitig beantworten.
> Es geht dabei um Deine Perl-Implementierung. 
> 
> Am Montag, 26. August 2002 00:19 schrieben Sie:
> > Hallo,
> >
> > Ich habe jetzt mal steak in perl geschrieben. Ist ganz schön langsam
> > geworden :-(((( Ich muss mal sehen, was sich noch optimieren lässt,
> > ich bin in perl noch nicht so bewandert.
> 
> Ich leider auch nicht.
> 
> >
> > Die jetzige Version kann mit mehreren Wörterbüchern umgehen und ist
> > auch schon auf andere Sprachen ausgelegt. (Ich habe leider kein
> > Wörterbuch für andere Sprachen). Was fehlt ist das Lesen der
> > Konfigurationsdatei. Ansonsten sind es hier und da noch einige
> > Schönheitskorrekturen und man kann in perl das ganze jetzt auch in
> > verschiedene Sprachen übersetzen(Hilfe und Ausgabekopf). Dann will
> > ich noch eine regexp-Suche einbauen, damit mal'n mit regular
> > expression suchen kann.
> >
> > Was mich am meisten stört ist, dass es so langsam ist. Mal sehen,
> > was die Perl-NG dazu spricht - vielleicht nehme ich auch zum Suchen
> > grep.
> >
> > Was ich mir noch überlegt habe, man könnte noch eine light-Version
> > schaffen, die halt nicht regexp und mehrere Wörterbücher bietet. Die
> > kann ja dann bash sein. Beide kommen mit der gleichen Konfig.-Datei
> > zurecht und akzepieren die gleichen Argumente (notfalls werden
> > einige ignoriert). Denn perl an sich ist schon ein kleines
> > Schlachtschiff.
> >
> > Jörg.
> 
> 
> Am Freitag, 30. August 2002 21:20 schrieben Sie:
> > Hi,
> >
> > ich habe jetzt das Programm mit Unterstützung von
> > de.comp.lang.perl.misc verbessert und es ist jetzt 5mal so schnell
> > wie vorher. Ist aber auch noch recht gut lesbar.
> > ....
> 
> Jörg, ich habe Deine alte und neue Version ausprobiert.
> Zuerst kann ich Dir nur eins sagen: Respekt! Viel Zeit investiert.
> 
> Ich habe mir die Performance von diesen Versionen angeschaut. Die
> zweite ist auf jeden Fall schneller. Die sind aber trotzdem langsamer
> als die Bash-Version. Einige Beispiele:
> 
> ----------------------------------------------------
> time steak -nowait -d ".*kk.*"
> -> real    0m0.670s
> 
> time ./Steak.pl --noclipboard -i kk
> -> real    0m5.428s
> ----------------------------------------------------
> time steak -nowait -d "hallo"
> -> real    0m0.459s
> 
> time ./Steak.pl --noclipboard -i hallo
> -> real    0m2.945s
> ----------------------------------------------------
> Ohne Ausgabe:
> 
> time steak -nowait -d ".*ZXias"
> -> real    0m0.388s
> 
> time ./Steak.pl --noclipboard -i ZXias
> -> real    0m2.607s
> ----------------------------------------------------
> 
> Ich glaube das liegt wohl an zwei Tatsachen.
> 1) Suchen im Datensatz
> 2) Die Ausgabe der Ergebnisse
> 
> Die Ausgabe der Ergebnisse ist bei Perl langsamer als bei der
> Bash-Version (siehe erste Beispiel mit vielen Ausgaben (ungefähr 107
> Zeilen) Außerdem habe ich das Gefühl (bin ich mir nicht sicher, denn
> ich kenne mich mit Perl nicht gut aus), daß die Such-Routine bei der
> Bash-Version schneller ist. Das liegt einfach daran, daß die
> Bash-Version "grep" verwendet. 
> 
> Als ich vor 3 Jahren mit der Entwicklung dieses Programms anfing,
> konnte ich ein wenig Shell-Programmierung. Aus diesem Grund habe ich
> es als Bash-Skript implementiert. Die Arbeit mit den Bash-Skripten ist
> aber sehr nervig. Manche Sachen funktionieren mit Sed, andere wiederum
> mit Awk usw. Es ist im allgemeinen sehr umständlich. Aus diesem Grund
> habe ich mir gedacht, daß ich es entweder in Perl oder in Python
> implementiere. Ich habe sogar eine Alpha-Version in Python geschrieben
> gehabt. Leider war diese Python-Version viel langsamer als seine
> Bash-Variante. 
> 
> Ich habe mich deswegen einige Male mit einigen Assistenten bei uns im 
> Fachbereich getroffen, und mich mit denen darüber unterhalten. 
> Meine Forschungen haben dies ergeben:
> 
> 1) Schnellste Lösung für eine Anfrage wäre der Einsatz von Indexen
> (zum Beispiel bei der Verwendung einer Datenbank). Man verwendet dazu 
> beispielsweise einen Primär-Index (z.B. Hash oder Sparse-Index) über
> die englische Wörter und einen Sekundär-Index (z.B. mittels
> Dense-Index) über die deutsche Wörter. Das Problem: Man braucht
> vielleicht eine Datenbank und außerdem ist dann Suchen nach Teilworte
> sehr aufwenig. Beispielsweise:
> 
> steak -nowait -d ".*hund"
> 
> liefert auch "Seehund", "Wachhund" usw. 
> 
> 2) Das Ersetzen von Bash-Skripten durch Perl bzw. Python würde den
> Entwickler das Leben erheblich erleichtern. Das Problem liegt aber bei
> diesen beiden Versionen (die Python von mir und die beiden
> Perl-Versionen von Dir) daran, daß sie meiner Meinung nach viel
> langsamer sind als die Shell-Skript-Version. Die Shell-Version
> verwendet grep, was echt sehr schnell arbeitet. 
> 
> Aber ein noch größeres Problem sehe ich wohl daran, daß man bei diesen
> beiden Versionen man vorher noch andere Pakete installiert habe muß,
> die nicht unbedingt bei jedem System installiert sind. Ich habe bei
> mir perl-5.6.0-81 installiert, was alleine fast 17MB groß ist. Im
> Gegensatz dazu sind Bash, Awk, sed usw. bei fast jedem System
> installiert.
> 
> 
> Am Freitag, 6. September 2002 02:03 schrieben Sie:
> > Razi Lotfi-Tabrizi schrieb am Thu 05. Sep, 22:18 (+0200) :
> > > Am Freitag, 23. August 2002 00:48 schrieben Sie:
> > > > joerg schrieb am Fri 23. Aug, 00:28 (+0200) :
> > > > Hello again,
> > > >
> > > > > Aber schon an der function find_dict habert es. Da du ja schon
> > > > > selbst awk verwendest, würde ich doch einfach mal prüfen, ob
> > > > > sich sowas in awk realisieren lässt. Wenn nicht würde ich perl
> > > > > vorschlagen, wenn ich es auch ungern nehme, weil es ein
> > > > > "Klotz" ist und ich eigentlich dachte, dass steak so auf einen
> > > > > Minisystem laufen könne.
> > > >
> > > > Und in awk habert es ab Prüfungen. Ich kann zum Beispiel nicht
> > > > prüfen, ob eine Datei existiert.
> > >
> > > Kann man test einbeziehen oder?
> >
> > Naja, ich hätte gern so wenig wie möglich andere Programme
> > eingebunden.
> 
> Ja, aber test ist eigentlich bei "sh-utils" dabei.
> 
> > Wenn man aber ein Shell-Script macht, in dem awk vorkommt, kann man
> > genauso test verwenden.
> 
> Ja
> 
> >
> > > Ich muß zugeben, daß Steak speziell für die Englisch-Deutsch
> > > ausgelegt ist. Das Problem liegt wohl beim Umgang mit Umlaute und
> > > ß. Um gewisse Funktionen anzubieten habe sogar eine dritte Spalt
> > > bei meinem Datensatz. Wenn man andere Sprachen einsetzen möchte,
> > > sollte man die Such-Routinen für die anderen Sprachen anders
> > > gestalten. Es ist sehr wichtig, daß die Funktionalität bei den
> > > neuen Versionen erhalten bleiben.
> > >
> > > Wenn man beispielsweise nach "daß" oder "dass" sucht, erhält man
> > > das gleiche Ergebnis; oder wenn man nach "groß" oder "gross" bzw.
> > > "während" oder "waehrend" sucht.
> >
> > Das wusste ich garnicht. Sowas ist ja overkill. Daraus sollte man
> > eine Option machen. Ansonsten sehe ich in Perl kein Problem.
> 
> Jaja, das Programm sieht zwar sehr klein aus. Man würde auch denken,
> daß es einfach wäre, so was zu programmieren. Das dachte ich auch.
> Meine erste Version war sowas wie eine erweiterte grep-Suche. Aber
> wenn man sich einigermaßen Zeit nimmt und sich mit allen möglichen
> Ausnahmen und Wünschen bezüglich der beiden Sprachen (deu, eng)
> beschäftigt, wird die Sache ein wenig doch komplizierter :-)
> 
> 
> >
> > > > Vielleicht,
> > > > wenn man etwas träumt könnte man sogar Übersetzungen über 2 WBer
> > > > zulassen. Also ein gibt ein de_en und ein fr_en und damit sind
> > > > auch Übersetzungen von de_fr möglich.
> > >
> > > Das wird sehr schwer. Fast unmöglich. Die Sprachen sind
> > > mehrdeutig.
> >
> > Das ist unmöglich. Für 3 Sprachen geht es noch halbwegs zu machen,
> > aber ich sehe ein absolutes Problem, wenn man über 4 Sprachen
> > übersetzen will. Das ist Pfade-Suchen in Prolog. Sowas sollte man
> > nicht machen, schon auch mit aus dem Grunde der Mehrdeutigkeiten.
> > cat $SCHNELL_SCHUSS > /dev/null
> 
> haha
> 
> >
> > Was ist, würdest du eine perl-Version akzeptieren? Ich habe mir auch
> > schon überlegt, man könnte ein Perl-Version machen und eine
> > tiny-version(in shell) die halt nicht alles unterstützt, aber die
> > Grundfunktion bietet.
> 
> Lieber Jörg, wie ich bereits in früheren Email erwähnt habe, würde ich
> mich sehr freuen, wenn dieses Programms weiter von der Linux-Gemeinde 
> weiterentwickelt wird. Ich bin zwar der jenige, der das Programm
> initiiert hat, trotzdem bin ich dafür, daß die weitere Entwicklung des
> Programms von der Mehrheit getragen werden sollte und nicht nur von
> mir.
> 
> Die Frage, die ich mir aber stelle ist, welche Vorteile (abgesehen von
> eine bequeme und agbeschlossen abgerundete Werkzeugmenge) bietet Perl,
> die Shell-Skript nicht bietet?
> 
> Die jetztige Perl-Version hat zur Zeit zwei Nachteile:
> 
> 1) Man muß zusätzlich noch Perl installiert haben.
> 2) Das Perl-Programm ist um Faktor 6 langsamer als die Shell-Variante.
> 
> Wie sieht es bei Perl mit der UNICODE-Unterschützung aus?
> Welche Vorteile bietet die Perl-Version Deiner Meinung nach?
> 
> Bevor wir aber jetzt alles umschreiben, sollten wir über unsere 
> Vorgehensweise und vorallem Ziele im Klaren sein.
> 
> Welche zusätzliche Eigenschaften sollte das Programm noch bieten?
> Einige Ergänzungswünsche von mir wären (bitte vervollständigen :-))
> 
> 1) Zusätzlich zum Standard-Datensatz auch  -- falls vorhanden -- 
> lokale user-gebundene Datensätze (in $HOME) nach regulären Ausdrücken
> suchen.
> 
> 2) Die neue Version darf nicht spürbar langsamer sein, als die
> jetztige Version.
> 
> 3) Die neue Version sollte vielleicht auch andere Sprachen
> unterstützen. Keine Ahnung aber wie das richtig funktionieren sollte!
> Mit anderen Sprachen meine ich nicht nur Sprachen wie französisch oder
> türkisch, sondern auch Sprachen wie persische (ja meine Muttersprache
> ;-)), arabisch, hebräisch usw., die nicht unbedingt ASCII sondern
> UNICODE brauchen. 
> 
> 4) Die neue Version darf aber nicht an Funktionalitäten bezüglich der 
> Unterstützung der Eigenheiten der deutschen Sprache einbüssen.
> 
> 5) Weiter sollte das Programm ISPELL (bzw. aSpell) verwenden können. 
> 
> 6) Eine gescheite Installationsroutine: Hier muß man sich mit
> autoconfig und automake beschäftigen. Man sollte das Programm -- wie
> üblich -- mit "./configure & make & make install" installieren können.
> Ich finde diesen Punkt sehr wichtig!
> 
> 7) Bei der Kompilierung (genauer gesagt bei ./configure) sollte man
> eine Option habe, mit deren Hilfe man die Kompilierung von
> "printbuffer" verhindert. "printbuffer" sollte auf jeden Fall beim
> Steak-Paket mitgeliefert werden. Auf "xcb" ist nicht immer Verlaß. Das
> "printbuffer"-Programm ist kompiliert nicht mal 20kByte. Jörg habe
> bitte ein Herz für dieses Programm :-). 
> 
> 8) Debian-Konforme Installation erlauben.
> 
> 9) Einige Veränderungen, damit man das Programm auch unter Windows
> (cygwin) verwenden kann (hallo Erik ;-)).
> 
> 10) Den Datensatz vielleicht vollkommen von dem Programm trennen und 
> bei einem anderen separaten CVS-Server integrieren!
> 
> 11) Das Programm "Steak/Datensatz/datenbankaktualisieren.sh"
> modifizieren, so daß es auch automatisch den aktuellen Datensatz von
> einer CVS-Server holen kann.
> 
> 
> 
> Naja, das sind wohl nur einige Punkte, die mir so einfielen. Welche
> andere Wünsche habt Ihr denn?
> 
> Ich hätte aber persönlich nichts gegen eine Perl-Version. Die Frage
> ist nur warum? Wenn man schon so weit geht, kann man auch gleich C/C++
> verwenden. Ich schätze mal, daß es bestimmt sehr gute freie
> Bibliotheken für das Suchen in einer Datei in C/C++ gibt. Bestimmt
> gibt so sowas auch bereits für UNICODE-Dateien (in Qt oder Gtk
> bestimmt).
> 
> 
> Auf jeden Fall wünsche ich Euch ein schönes Wochenende.
> 
> Tschüß
> Razi
> 
> 
> ps: Jörg, neue Datensätz für andere Sprachen bekommst Du
> beispielsweise unter: www.freedic.de
> 
> ps:ps: Tut mir Leid, wenn diese Email so lang geworden ist :-)
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Steak-developer mailing list
> Ste...@li...
> https://lists.sourceforge.net/lists/listinfo/steak-developer