Re: [Steak-developer] Re: steak

[Joerg S. <jo...@al...>]

Razi Lotfi-Tabrizi schrieb :
> ----------------------------------------------------
>  [time Messungen]
> ----------------------------------------------------

Wenn ich die Ergebnisse so sehe, kann es seien, dass ich dir nicht meine
eng=FCltige Version geschickt habe.

$ 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.

> Ich glaube das liegt wohl an zwei Tatsachen.
> 1) Suchen im Datensatz
> 2) Die Ausgabe der Ergebnisse

Nein, mit der Ausgabe hat es nichts zu tun. Es ist wirklich eine Frage
der Suche. Ich habe zum Beispiel anfangs mit auf leere Zeilen geschaut
und dann diese garnicht erst durchsucht. Aber dieser Vergleich kostet
schon eine halbe Sekunde.

> Die Ausgabe der Ergebnisse ist bei Perl langsamer als bei der Bash-Vers=
ion=20
> (siehe erste Beispiel mit vielen Ausgaben (ungef=E4hr 107 Zeilen)

Bei mir 163.

> Au=DFerdem habe ich das Gef=FChl (bin ich mir nicht sicher, denn ich ke=
nne mich=20
> mit Perl nicht gut aus), da=DF die Such-Routine bei der Bash-Version sc=
hneller=20
> ist. Das liegt einfach daran, da=DF die Bash-Version "grep" verwendet.=20

Ja und das wird auch nie anders. An Perl h=E4ngt noch so ein Schwanz dran=
,
das kann nie so gut werden, wie ein hochoptimiertes grep.

> 1) Schnellste L=F6sung f=FCr eine Anfrage w=E4re der Einsatz von Indexe=
n (zum=20
> Beispiel bei der Verwendung einer Datenbank). Man verwendet dazu=20
> beispielsweise einen Prim=E4r-Index (z.B. Hash oder Sparse-Index) =FCbe=
r die=20
> englische W=F6rter und einen Sekund=E4r-Index (z.B. mittels Dense-Index=
) =FCber die=20
> deutsche W=F6rter. Das Problem: Man braucht vielleicht eine Datenbank u=
nd=20
> au=DFerdem ist dann Suchen nach Teilworte sehr aufwenig. Beispielsweise=
:
>=20
> steak -nowait -d ".*hund"
>=20
> liefert auch "Seehund", "Wachhund" usw.=20

Ich w=FCrde 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=F6rter und rechts 4
W=F6rter stehen? Also ich sehe ehr einen positiven Punkt in einem Text al=
s
Datenbasis.

> 2) Das Ersetzen von Bash-Skripten durch Perl bzw. Python w=FCrde den En=
twickler=20
> das Leben erheblich erleichtern. Das Problem liegt aber bei diesen beid=
en=20
> Versionen (die Python von mir und die beiden Perl-Versionen von Dir) da=
ran,=20
> da=DF sie meiner Meinung nach viel langsamer sind als die Shell-Skript-=
Version.
> Die Shell-Version verwendet grep, was echt sehr schnell arbeitet.=20

Finde ich nicht.
$ time grep -i hallo /usr/share/trans/de-en > /dev/null

real    0m0.238s
user    0m0.070s
sys     0m0.040s
$ time grep -i kk /usr/share/trans/de-en > /dev/null

real    0m0.282s
user    0m0.090s
sys     0m0.080s

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=FCrde ich einen steak-tiny vorschlagen, der eben
alss Shellscript implementiert ist, aber nur die Funktionen bietet, die
er kann.

> Aber ein noch gr=F6=DFeres Problem sehe ich wohl daran, da=DF man bei d=
iesen beiden=20
> Versionen man vorher noch andere Pakete installiert habe mu=DF, die nic=
ht=20
> unbedingt bei jedem System installiert sind. Ich habe bei mir perl-5.6.=
0-81=20
> installiert, was alleine fast 17MB gro=DF ist. Im Gegensatz dazu sind B=
ash,=20
> Awk, sed usw. bei fast jedem System installiert.

Und genauso w=FCrde ich =FCber Python fluchen. Ich Debian ist sehr viel m=
it
Perl gemacht und daher geh=F6rt 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 =FCbersetzt. Und daf=FCr sehe ich eben eine -tiny Version.


>> > Wenn man beispielsweise nach "da=DF" oder "dass" sucht, erh=E4lt man=
 das
>> > gleiche Ergebnis; oder wenn man nach "gro=DF" oder "gross" bzw. "w=E4=
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.
>=20
> Jaja, das Programm sieht zwar sehr klein aus. Man w=FCrde auch denken, =
da=DF es=20

Nein, ich sehe das als eine unerw=FCnschte Funktionalit=E4t an. Wenn ich =
nach
dem Wort wei=DF (von wissen) suche, bekomme ich viele viele Ergebnisse, d=
ie
nicht dahin geh=F6ren. Sowas w=FCrde ich sagen ist eine Option, aber kein
Standard. Ich wei=DF nicht, was du f=FCr ein W=F6rterbuch verwendest, abe=
r
meines hat keine ae,oe,ss. Ich denke sowas w=E4re auch falsch, da somit i=
m
W=F6rterbuch eine falsche Schreibweise steht und mit der neuen
Rechtschreibung ist es bei ss schwierig zu sagen, was nun richtig ist.

$ head /usr/share/trans/de-en=20
# German :: English word list
# Version :: 1.2 2002-07-31
# Copyright (c) :: Frank Richter <Fra...@hr...>, 1995=
 - 2002
# License :: GPL Version 2; GNU General Public License
# URL :: http://dict.tu-chemnitz.de/

> Die Frage, die ich mir aber stelle ist, welche Vorteile (abgesehen von =
eine=20
> bequeme und agbeschlossen abgerundete Werkzeugmenge) bietet Perl, die=20
> Shell-Skript nicht bietet?

In der Shell gibt ees zwar Arrays, aber die sind nicht gerade das gelbe
vom Ei. Wie k=F6nnte man es also anstellen, dass man aus eine
Konfigurationsdatei die W=F6rterb=FCcher 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")

Zum Ende sollen alle W=F6rterb=FCcher 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:
>=20
> 1) Man mu=DF zus=E4tzlich noch Perl installiert haben.
> 2) Das Perl-Programm ist um Faktor 6 langsamer als die Shell-Variante.
>=20
> Wie sieht es bei Perl mit der UNICODE-Untersch=FCtzung aus?

$ search perl unicode
libunicode-maputf8-perl - Perl module for conversing between any characte=
r 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.

> 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=FCrbar langsamer sein, als die jetzti=
ge=20
> 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=FCtz=
en.
> Keine Ahnung aber wie das richtig funktionieren sollte! Mit anderen Spr=
achen=20
> meine ich nicht nur Sprachen wie franz=F6sisch oder t=FCrkisch, sondern=
 auch=20
> Sprachen wie persische (ja meine Muttersprache ;-)), arabisch, hebr=E4i=
sch=20
> usw., die nicht unbedingt ASCII sondern UNICODE brauchen.=20

Wie soll das gehen? Hast du schonmal ein funktionierendes unicode System
gesehen? Ich wollte letztends die Console auf unicode umstellen, aber
welche Shell unterst=FCtzt das? :-((

> 4) Die neue Version darf aber nicht an Funktionalit=E4ten bez=FCglich d=
er=20
> Unterst=FCtzung der Eigenheiten der deutschen Sprache einb=FCssen.

Was hei=DFt Eigenheiten? Wie oben schon gesagt, ich sehe darin keine
wirkliche Funktion. Durch was will ein Franzose sein =E1 ersetzen oder ei=
n
Spanier sein =F5. Das geh=F6rt zur Deutschen Sprache.

> 6) Eine gescheite Installationsroutine: Hier mu=DF man sich mit autocon=
fig und=20
> automake besch=E4ftigen. Man sollte das Programm -- wie =FCblich -- mit=
=20
> "./configure & make & make install" installieren k=F6nnen. Ich finde di=
esen=20
> Punkt sehr wichtig!

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

> 7) Bei der Kompilierung (genauer gesagt bei ./configure) sollte man ein=
e=20
> Option habe, mit deren Hilfe man die Kompilierung von "printbuffer"=20
> verhindert. "printbuffer" sollte auf jeden Fall beim Steak-Paket mitgel=
iefert=20
> werden. Auf "xcb" ist nicht immer Verla=DF. Das "printbuffer"-Programm =
ist=20
> kompiliert nicht mal 20kByte. J=F6rg habe bitte ein Herz f=FCr dieses P=
rogramm=20
> :-).=20

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=FCchti=
g
ist ohne xlibs. Ohne printbuffer, habe ich die M=F6glichkeit zu testen (-=
x)
ob xcb ausf=FChrbar ist und damit wei=DF ich, dass es geht. Bringe ich ab=
er
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=FCft, ob xlibs da sind, wenn
ja l=E4dt es diese, wenn nein endet es in einem definierten Zustand (was
bei den dyn. linken nicht m=F6glicht ist)

> 8) Debian-Konforme Installation erlauben.

Das ist uninteressant. Was das Debian-Paket brauch, wird hinterher durch
einen Patch ge=E4ndert.

> 10) Den Datensatz vielleicht vollkommen von dem Programm trennen und=20
> bei einem anderen separaten CVS-Server integrieren!

%-) Wie jetzt, das verstehe ich nicht ganz.

> 11) Das Programm "Steak/Datensatz/datenbankaktualisieren.sh" modifizier=
en, so=20
> da=DF es auch automatisch den aktuellen Datensatz von einer CVS-Server =
holen=20
> kann.

W=FCrde ich nicht f=FCr 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?


> Ich h=E4tte aber pers=F6nlich nichts gegen eine Perl-Version. Die Frage=
 ist nur=20
> warum? Wenn man schon so weit geht, kann man auch gleich C/C++ verwende=
n. Ich=20

Das stimmt, aber woher holst du dann die regexp? Selbst implementieren?
Nicht wirklich. Eine andere Lib nutzen? Da sind wieder die sch=F6nen,
ungewollten Abh=E4ngigkeiten und da kann man auch gleich grep nehmen.

> sch=E4tze mal, da=DF es bestimmt sehr gute freie Bibliotheken f=FCr das=
 Suchen in=20
> einer Datei in C/C++ gibt. Bestimmt gibt so sowas auch bereits f=FCr=20

Was macht dann noch das Programm? Wir wollen kein Shellscript in C
schreiben!

> UNICODE-Dateien (in Qt oder Gtk bestimmt).

Wieso denkst du schon =FCber unicode nach? Wenn vielleicht alles
schiefgeht, wird der gekippt und noch bevor wir was davon gesehen haben,
kommt der 32-Bit-Code.

> ps: J=F6rg, neue Datens=E4tz f=FCr andere Sprachen bekommst Du beispiel=
sweise unter:
> www.freedic.de

Und wie sind die strukturiert? lang1 :: lang2

Bye, J=F6rg.