Re: [Steak-developer] Re: steak

[Razi Lotfi-T. <raz...@we...>]

Am Samstag, 7. September 2002 13:52 schrieben Sie:
> Razi Lotfi-Tabrizi schrieb :
> > ----------------------------------------------------
> >  [time Messungen]
> > ----------------------------------------------------
>
> Wenn ich die Ergebnisse so sehe, kann es seien, dass ich dir nicht meine
> engültige Version geschickt habe.

Doch das war zu der Zeit die zweite Version, die ich von Dir erhielt.

>
> $ time perl steak.pl -i --noclipboard hallo > /dev/null
>
> real    0m1.333s
> user    0m1.160s
> sys     0m0.060s
> $ time perl steak.pl -i --noclipboard kk > /dev/null
>
> real    0m1.360s
> user    0m1.180s
> sys     0m0.050s
>
> [Bei diesen Zeiten ist schon die Durchsuchung einer 2. Datei
> eingeschlossen.]
>
> Oder du hast, den Werten nach, einen P166.

K6-II 400Mh.


> > Die Ausgabe der Ergebnisse ist bei Perl langsamer als bei der
> > Bash-Version (siehe erste Beispiel mit vielen Ausgaben (ungefähr 107
> > Zeilen)
>
> Bei mir 163.
>

Du hast wohl eine neue Version des Datensatzes, oder?

> > 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.
>
> Ja und das wird auch nie anders. An Perl hängt noch so ein Schwanz dran,
> das kann nie so gut werden, wie ein hochoptimiertes grep.

Weißt Du, ob agrep für Perl gibt?

>
> > 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.
>
> Ich würde sagen, mit Indizes kann man nicht arbeiten. Einmal, weil man
> auch Teilworte und Wortgruppen sucht und das andere Problem ist. was will
> man als Index nehmen in einer Spalte, wo links 4 Wörter und rechts 4
> Wörter stehen? Also ich sehe ehr einen positiven Punkt in einem Text als
> Datenbasis.

Das sehe ich auch so. Aber in einer Index-Datei (siehe Glimpse) kann man auch 
nach reg. Ausdrücke suchen. Wie, weiß ich auch nicht! Aber ich kenne mich mit 
Glimpse auch nicht so gut aus.


>
>
> Der Unterschied bei mir ist ~1 Sekunde. Ich spekuliere mit folgendem,
> heutzutage sind die Rechner wesentlich schneller als mein K6-300. Von
> daher wird der Unterschied garnichtmehr auffallen. Auf Rechnern, die
> jedoch langsamer sind, würde ich einen steak-tiny vorschlagen, der eben
> alss Shellscript implementiert ist, aber nur die Funktionen bietet, die
> er kann.

Finde ich auch OK. Aber schau Dir mal zuert bitte Magic-Dic an.

>
> > 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.
>
> Und genauso würde ich über Python fluchen. 
Ja
> Ich Debian ist sehr viel mit
> Perl gemacht und daher gehört es fast zur Standardinstallation. Bei
> anderen Systemen kann es schon wieder anders aussehen und auf einem
> Server will man nicht irgendein riesen Paket installieren, weil man 3 mal
> im Jahr was übersetzt. Und dafür sehe ich eben eine -tiny Version.

OK

>
> >> > 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 hat damit zutun, daß viele Leute (z.B. bei den Email) sich eher an 
ASCII-7 halten und dadruch keine ß oder Umlaute bei den deutschen Texten 
verwenden.


> >>
> >> 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
>
> Nein, ich sehe das als eine unerwünschte Funktionalität an. Wenn ich nach
> dem Wort weiß (von wissen) suche, bekomme ich viele viele Ergebnisse, die
> nicht dahin gehören. 



steak -d -nowait weiß
--------------------------------------------------
          Deutsch     ->     English
  1 ) weiß  :==  knows
  2 ) weiß  :==  whitely

---------- Jetzt die Kontext-Eintraege ----------
          Deutsch     ->     English
  1 ) Er weiß nicht, was er tun soll.  :==  He's in a quandary.
  2 ) Ich weiß davon.  :==  I know about it.
  3 ) Ich weiß es wirklich nicht.  :==  I'm blessed if I know.
  4 ) Ich weiß es wirklich nicht.  :==  I'm sure I don't know.
  5 ) Ich weiß nicht, was ich tun soll.  :==  I'm at a loss what to do.
  6 ) Ich weiß, was ich will.  :==  I know my own mind.
  7 ) Man weiß nie.  :==  You never know.
  8 ) Schwarz-Weiß-Bildschirm {m}  :==  monochrome terminal
  9 ) Soviel ich weiß.  :==  As far as I know.
 10 ) Und ob ich es weiß!  :==  Don't I know it!
 11 ) geweißt, machte weiß  :==  whitened
 12 ) ich weiß davon  :==  I know about it
 13 ) ich weiß genau, dass du es nicht (tun) kannst  :==  I defy you to do it
 14 ) ich weiß kein Wort davon  :==  I don't know a thing about it
 15 ) ich weiß nicht, was ich tun soll  :==  I'm at a loss what to do
 16 ) ich weiß nichts davon  :==  I don't know anything about it
 17 ) ich weiß, wo der Schuh drückt  :==  I know where the shoe pinches
 18 ) macht weiß  :==  whitens
 19 ) macht weiß, weißt  :==  whites
 20 ) machte weiß  :==  whited
 21 ) schwarz auf weiß  :==  in cold print
 22 ) soviel ich weiß  :==  for all I know
 23 ) soviel ich weiß  :==  for aught I know
 24 ) soviel ich weiß  :==  to my knowledge
 25 ) soviel ich weiß; meines Wissens  :==  to my knowledge
 26 ) weiß (Farbe)  :==  white
 27 ) weiß der Henker  :==  fuck knows
 28 ) weiß machen  :==  to whiten




Welche Ergebnisse gehören nicht darein?


> Sowas würde ich sagen ist eine Option, aber kein
> Standard. Ich weiß nicht, was du für ein Wörterbuch verwendest, aber
> meines hat keine ae,oe,ss. Ich denke sowas wäre auch falsch, da somit im
> Wörterbuch eine falsche Schreibweise steht und mit der neuen
> Rechtschreibung ist es bei ss schwierig zu sagen, was nun richtig ist.
>

> > 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?
>

> In der Shell gibt ees zwar Arrays, aber die sind nicht gerade das gelbe
> vom Ei. Wie könnte man es also anstellen, dass man aus eine
> Konfigurationsdatei die Wörterbücher ausliest.
> add_dict("/usr/share/trans/de-en", "de", "en")
> add_dict("/usr/share/trans/fr-de", "fr", "de")
> add_dict("~/.en-de", "en", "de")

Vielleicht kann uns dazu Jens mehr sagen.


>
> Zum Ende sollen alle Wörterbücher durchsucht werden, die der Benutzer
> angegeben hat. Und das auf der richtigen Seite. Man braucht also einen
> 2-dim. Array und den gibt es IMO nicht in der Shell.
>
> > 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?
>
> $ search perl unicode
> libunicode-maputf8-perl - Perl module for conversing between any character
> sets and UTF8 libunicode-map-perl - Perl module for mapping charsets from
> and to utf16 unicode libunicode-map8-perl - Perl module to map 8bit
> character sets to Unicode libunicode-string-perl - Perl modules for Unicode
> strings
>
> Aber frag mich nicht. Mit grep sieht es da IMHO schlechter aus.

Ja, das weiß ich auch! Leider. Es kann aber sein, daß agrep UNICODE 
unterstützt.




>
> > Welche Vorteile bietet die Perl-Version Deiner Meinung nach?
>
> Einerseits s.o. und andererseits, dass es eine Programmiersprache ist.
>
> > 2) Die neue Version darf nicht spürbar langsamer sein, als die jetztige
> > Version.
>
> Das geht per Definition schon garnicht. Jemehr Funktionen wir hinein
> packen, desto langsamer wird es. Es muss eine abgespeckte Version geben.
>
> > 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.
>
> Wie soll das gehen? Hast du schonmal ein funktionierendes unicode System
> gesehen? Ich wollte letztends die Console auf unicode umstellen, aber
> welche Shell unterstützt das? :-((

Bei DICT (kombiniert mit Mozilla 7.0 als Client) habe ich es ausprobiert. Es 
funktioniert. Aber auf der Konsole habe ich es auch nicht geschafft.
Aber meine System ist ein wenig veraltert.
Irgendwann will ich SuSE-8.1 installieren. Mal sehen, ob ich es danach doch 
schaffe.

 

>
> > 4) Die neue Version darf aber nicht an Funktionalitäten bezüglich der
> > Unterstützung der Eigenheiten der deutschen Sprache einbüssen.
>
> Was heißt Eigenheiten? Wie oben schon gesagt, ich sehe darin keine
> wirkliche Funktion. Durch was will ein Franzose sein á ersetzen oder ein
> Spanier sein õ. Das gehört zur Deutschen Sprache.

Wenn man das Programm trennt in tiny und eine große Version, dann ist es egal.

>
> > 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!
>

> Kannst du mir mal bitte, interessenhalber, erklären, wozu
> auto{make,config} gut sind? Was machen diese lustigen Programme?

Es ist bei der Installation der Unix-Software ist es fast ein Standard, 
configure und make zu verwenden. Es wäre nicht schlecht, wenn das Steak sich 
auch daran halten könnte. Ist aber auch nicht so 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
> >
> > :-).
>
> Ich kann dieses Programm nicht mitnehmen. Denn wenn ich es mit aufnehme,
> muss ich in die Dependencies xlib schreiben und das ist wieder ein riesen
> Klotz. Das Problem ist, dass das Paket nicht vollkommen funktionstüchtig
> ist ohne xlibs. Ohne printbuffer, habe ich die Möglichkeit zu testen (-x)
> ob xcb ausführbar ist und damit weiß ich, dass es geht. Bringe ich aber
> selbst printbuffer mit, dann ist es immer installiert, muss aber nicht
> funktionieren, falls keine xlibs da sind. Die einzigste Chance, die ich
> sehe, printbuffer arbeitet mit dlopen und prüft, ob xlibs da sind, wenn
> ja lädt es diese, wenn nein endet es in einem definierten Zustand (was
> bei den dyn. linken nicht möglicht ist)

Das könnte man doch in der Configure-Routine herausfinden, ob xlib 
installiert ist oder nicht.

>
> > 8) Debian-Konforme Installation erlauben.
>
> Das ist uninteressant. Was das Debian-Paket brauch, wird hinterher durch
> einen Patch geändert.

OK. Ich kenne mich mit Debian nicht aus, deswegen habe ich es geschrieben 
gehabt.


>
> > 10) Den Datensatz vielleicht vollkommen von dem Programm trennen und
> > bei einem anderen separaten CVS-Server integrieren!
>
> %-) Wie jetzt, das verstehe ich nicht ganz.

Siehe freedict.de


>
> > 11) Das Programm "Steak/Datensatz/datenbankaktualisieren.sh"
> > modifizieren, so daß es auch automatisch den aktuellen Datensatz von
> > einer CVS-Server holen kann.
>
> Würde ich nicht für Debian nutzen, da es unter Debian ein Paket
> trans-de-en gibt, dass mir immer die aktuelle Version der o.g. Datenbank
> bietet. Was will man mehr?

Was ist das für ein Programm? Gibt es auch allgemein für Linux?


>
> > 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
>
> Das stimmt, aber woher holst du dann die regexp? Selbst implementieren?
> Nicht wirklich. Eine andere Lib nutzen? Da sind wieder die schönen,
> ungewollten Abhängigkeiten und da kann man auch gleich grep nehmen.

Warum Abhängigkeiten?
Ja, warum nicht! Mann nicht beispielsweise Teile von grep!


>
> > 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
>
> Was macht dann noch das Programm? Wir wollen kein Shellscript in C
> schreiben!

Naja, kein Kommentar.


>
> > UNICODE-Dateien (in Qt oder Gtk bestimmt).
>
> Wieso denkst du schon über unicode nach? Wenn vielleicht alles
> schiefgeht, wird der gekippt und noch bevor wir was davon gesehen haben,
> kommt der 32-Bit-Code.

Das heiß aber nicht, daß man dann Unicode nie mehr verwendet! Oder glaubst 
Du, daß wenn Unicode sich durchsetzt, ASCII keine Verwendung finden 
wird? 


Tschüß
Razi