steak-developer Mailing List for Steak
Brought to you by:
razilotfi
Menu
▾
▴
steak-developer — Developer Mailing List for "Steak" dictionary.
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(6) |
Sep
(26) |
Oct
|
Nov
(4) |
Dec
|
|---|
|
From: Razi Lotfi-T. <raz...@we...> - 2002-11-12 23:21:31
|
Joerg Sommer schrieb:
> Jens Röder <j.r...@tu...> wrote:
> > On Fri, 8 Nov 2002, Joerg Sommer wrote:
> >
> >> Ich hab es mir jetzt endlich mal geholt. Auf den ersten Blick bin ich
> >> nicht begeistert. Man will die bash (was ist an der bash besser als an
> >> einer POSIX-Shell?)
> >
> > gut, magst sicherlich Recht haben, aber bash ist die Shell, dir mir zuerst
> > unter die Finger kam und ich bin einfach noch im Lernprozeß.
>
> OK, aber ich würde als Ziel eine POSIX-Shell anstreben, da es da richtig
> schöne kleine Shells gibt, z.B. dash, mit denen man das auch nutzen kann
> und unter anderen OSen muss nicht mal eine bash vorhanden sein.
>
> >> und dann sind die install-Scripte recht vergurkt.
> >
> > Was stört Dich daran? Es offeriert eine globale Installation, die ich
>
> #v+
> $ cat install
>
> bash install.bash
> $ head install.bash
> #!/bin/bash
>
> #check bash
> : ${BASH_VERSINFO:=0}
>
> if [ ${BASH_VERSINFO[0]} -lt 2 ] ; then
> echo 'bash version might be too old. Please use one above 2.*'
> exit 1
> fi
> #v-
>
> wäre besser folgendes in einer Datei.
>
> #v+
> if [ "${SHELL##*/}" != bash ]; then
> exec bash $0
> fi
> #v-
>
> >> Was jedoch viel versprechend aussieht, sind die vielen Wörterbücher.
> >> Ehrlich gesagt, habe ich nicht gerade viel Lust, mich durch di
> >> durchzuwühlen, um zu sehen, wo ich alles /usr/local/bla rausschreiben
> >> muss und was ich ändern muss, damit ich di im aktuellen Verzeichnis
> >> ausführen kann.
> >
> > s.o., das Skript bietet auch Installation nur ins $HOME, was aber
> > Platzverschwendung auf einer Multiuser Maschine ist, wenn das jeder macht.
>
> Das hab ich gar nicht gesehen. danke.
>
> >> Ich jemanden eine Mailinglist oder besser eine
> >> Newsgroup zu Magic-Dic bekannt?
> >
> > Ist mir selber nicht bekannt. Dafür ist das Projekt auch zu neu. Bin aber
> > für Tips und Kritik dankbar.
>
> Da kann ich nicht dienen. Ich habe mir das Programm nur flüchtig
> angesehen und nach dem mir das Installskript spanisch vor kam hab ich mir
> das noch nicht richtig angesehen. (Ich hatte in Wirklichkeit keine
> richtige Lust und da die ersten Zeilen kurkig aussahen, habe ich gar
> nicht weiter gelesen.) Aber ich sehe es mir gern mal an und gebe dazu
> eine Kritik ab. Dürfen wir diese ML dazu gleich verwenden, Razi?
>
Wenn es sein muß!
Obwohl ich es eigentlich nicht mag von Dir (Jörg) Emails zu lesen.
Das war nicht ernst gemeint :-)))
Aber wir hatten erst vorgestern den 11.11 :-)
Natürlich kann diese Diskussion über diese Mailingliste laufen. Würde mich auch
sehr interessieren, auf dem laufenden zu bleiben.
Bis dann
Tschüß
Razi
>
> Jörg.
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> To learn the basics of securing your web site with SSL,
> click here to get a FREE TRIAL of a Thawte Server Certificate:
> http://www.gothawte.com/rd522.html
> _______________________________________________
> Steak-developer mailing list
> Ste...@li...
> https://lists.sourceforge.net/lists/listinfo/steak-developer
|
|
From: Joerg S. <jo...@al...> - 2002-11-12 21:21:03
|
Jens R=F6der <j.r...@tu...> wrote:
> On Fri, 8 Nov 2002, Joerg Sommer wrote:
>=20
>> Ich hab es mir jetzt endlich mal geholt. Auf den ersten Blick bin ich
>> nicht begeistert. Man will die bash (was ist an der bash besser als an
>> einer POSIX-Shell?)
>=20
> gut, magst sicherlich Recht haben, aber bash ist die Shell, dir mir zue=
rst
> unter die Finger kam und ich bin einfach noch im Lernproze=DF.
OK, aber ich w=FCrde als Ziel eine POSIX-Shell anstreben, da es da richti=
g
sch=F6ne kleine Shells gibt, z.B. dash, mit denen man das auch nutzen kan=
n
und unter anderen OSen muss nicht mal eine bash vorhanden sein.
>> und dann sind die install-Scripte recht vergurkt.
>=20
> Was st=F6rt Dich daran? Es offeriert eine globale Installation, die ich
#v+
$ cat install
bash install.bash
$ head install.bash=20
#!/bin/bash
#check bash
: ${BASH_VERSINFO:=3D0}
if [ ${BASH_VERSINFO[0]} -lt 2 ] ; then
echo 'bash version might be too old. Please use one above 2.*'
exit 1
fi
#v-
w=E4re besser folgendes in einer Datei.
#v+
if [ "${SHELL##*/}" !=3D bash ]; then
exec bash $0
fi
#v-
>> Was jedoch viel versprechend aussieht, sind die vielen W=F6rterb=FCche=
r.
>> Ehrlich gesagt, habe ich nicht gerade viel Lust, mich durch di
>> durchzuw=FChlen, um zu sehen, wo ich alles /usr/local/bla rausschreibe=
n
>> muss und was ich =E4ndern muss, damit ich di im aktuellen Verzeichnis
>> ausf=FChren kann.
>=20
> s.o., das Skript bietet auch Installation nur ins $HOME, was aber
> Platzverschwendung auf einer Multiuser Maschine ist, wenn das jeder mac=
ht.
Das hab ich gar nicht gesehen. danke.
>> Ich jemanden eine Mailinglist oder besser eine
>> Newsgroup zu Magic-Dic bekannt?
>=20
> Ist mir selber nicht bekannt. Daf=FCr ist das Projekt auch zu neu. Bin =
aber
> f=FCr Tips und Kritik dankbar.
Da kann ich nicht dienen. Ich habe mir das Programm nur fl=FCchtig
angesehen und nach dem mir das Installskript spanisch vor kam hab ich mir
das noch nicht richtig angesehen. (Ich hatte in Wirklichkeit keine
richtige Lust und da die ersten Zeilen kurkig aussahen, habe ich gar
nicht weiter gelesen.) Aber ich sehe es mir gern mal an und gebe dazu
eine Kritik ab. D=FCrfen wir diese ML dazu gleich verwenden, Razi?
J=F6rg.
|
|
From: <j.r...@tu...> - 2002-11-11 17:30:15
|
Hi, On Fri, 8 Nov 2002, Joerg Sommer wrote: > Ich hab es mir jetzt endlich mal geholt. Auf den ersten Blick bin ich > nicht begeistert. Man will die bash (was ist an der bash besser als an > einer POSIX-Shell?) gut, magst sicherlich Recht haben, aber bash ist die Shell, dir mir zuerst unter die Finger kam und ich bin einfach noch im Lernproze=DF. > und dann sind die install-Scripte recht vergurkt. Was st=F6rt Dich daran? Es offeriert eine globale Installation, die ich empfehle oder eine only local ins $HOME f=FCr Leute ohne root-Rechte auf de= r Kiste. Was h=E4ttest Du gerne anders? > Was jedoch viel versprechend aussieht, sind die vielen W=F6rterb=FCcher. > Ehrlich gesagt, habe ich nicht gerade viel Lust, mich durch di > durchzuw=FChlen, um zu sehen, wo ich alles /usr/local/bla rausschreiben > muss und was ich =E4ndern muss, damit ich di im aktuellen Verzeichnis > ausf=FChren kann. s.o., das Skript bietet auch Installation nur ins $HOME, was aber Platzverschwendung auf einer Multiuser Maschine ist, wenn das jeder macht. > Ich jemanden eine Mailinglist oder besser eine > Newsgroup zu Magic-Dic bekannt? Ist mir selber nicht bekannt. Daf=FCr ist das Projekt auch zu neu. Bin aber f=FCr Tips und Kritik dankbar. Beste Gr=FC=DFe JR ---------------------------------------------------------------------------= -- Physikalische und Theoretische Chemie der TU-Braunschweig Jens R=F6der, Hans-Sommer Str.10, 38106 Braunschweig ---------------------------------------------------------------------------= -- |
|
From: Joerg S. <jo...@al...> - 2002-11-08 13:32:27
|
Razi Lotfi-Tabrizi <raz...@we...> wrote: > Hi J=F6rg, Hallo, nach langer Zeit mal wieder. > H=E4ttest Du wohl gerne! Hast Du Magic-Dic ausprobiert? Ich hab es mir jetzt endlich mal geholt. Auf den ersten Blick bin ich nicht begeistert. Man will die bash (was ist an der bash besser als an einer POSIX-Shell?) und dann sind die install-Scripte recht vergurkt. Was jedoch viel versprechend aussieht, sind die vielen W=F6rterb=FCcher. Ehrl= ich gesagt, habe ich nicht gerade viel Lust, mich durch di durchzuw=FChlen, u= m zu sehen, wo ich alles /usr/local/bla rausschreiben muss und was ich =E4ndern muss, damit ich di im aktuellen Verzeichnis ausf=FChren kann. Ic= h jemanden eine Mailinglist oder besser eine Newsgroup zu Magic-Dic bekannt= ? Was wird nun aus steak? J=F6rg. |
|
From: Martin W. <97...@st...> - 2002-09-30 23:37:27
|
Bei dieser g=E4hnenden Lehre in der Mailing-Liste muss ich doch auch mal was sagen... Hier is noch jemand... Hab mich in letzter Zeit mit automake-Support f=FCr steak befasst und die= erste Version ist fertig. Das 40k gro=DFe Paket hab ich Razi geschickt, hoffe es ist angekommen. Kommt nicht auf die Idee, steak einzustampfen, alleine weitermachen macht n=E4mlich keinen Spa=DF ;-) steak l=E4uft =FCbrigens auch unter Solaris, sofern man GNU grep und Textutils (wegen nl) verwendet. Also, weitermachen! Martin |
|
From: Martin W. <97...@st...> - 2002-09-26 08:50:19
|
Bei dieser g=E4hnenden Lehre in der Mailing-Liste muss ich doch auch mal
was sagen...
Hier is noch jemand...
Hab mich in letzter Zeit mit automake-Support f=FCr steak befasst und die=
erste Version ist fertig. Das 40k gro=DFe Paket hab ich Razi geschickt,
hoffe es ist angekommen. Kommt nicht auf die Idee, steak einzustampfen,
alleine weitermachen macht n=E4mlich keinen Spa=DF ;-)
steak l=E4uft =FCbrigens auch unter Solaris, sofern man GNU grep und
Textutils (wegen nl) verwendet.
Also, weitermachen!
Martin
|
|
From: Razi Lotfi-T. <raz...@we...> - 2002-09-25 08:18:36
|
Joerg Sommer schrieb: > Hi, Hi Jörg, > > > ist hier noch jemand? Nee, wir sind alle zu einer anderen Mailing-Liste ausgewichen und Dir nichts gesagt :-))) > Wurde steak etwa schon eingestampft? ;) Hättest Du wohl gerne! Hast Du Magic-Dic ausprobiert? Tschüß Razi > > > Jörg. > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Steak-developer mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/steak-developer |
|
From: Joerg S. <jo...@al...> - 2002-09-25 04:24:03
|
Hi, ist hier noch jemand? Wurde steak etwa schon eingestampft? ;) J=F6rg. |
|
From: Joerg S. <jo...@al...> - 2002-09-12 16:28:29
|
Razi Lotfi-Tabrizi <raz...@we...> wrote:
>> >> Kannst du mir mal bitte, interessenhalber, erkl=E4ren, wozu
>> >> auto{make,config} gut sind? Was machen diese lustigen Programme?
>> >
>> > Es ist bei der Installation der Unix-Software ist es fast ein Standa=
rd,
>> > configure und make zu verwenden. Es w=E4re nicht schlecht, wenn das =
Steak
>> > sich auch daran halten k=F6nnte. Ist aber auch nicht so wichtig!
>>
>> make w=FCrde ich so und so nehmen. Ich k=F6nnte mir ein Leben ohne mak=
e
>> garnicht vorstellen :-)
>=20
> Ich glaube, ich komme um diese Automake und Autoconfigure nicht mehr he=
rum.=20
Ich wei=DF nicht, was dein configure erledigen soll, aber ich w=FCrde den=
ken:
nichts. mach doch einfach eine shell-schript, das ausgibt, dass nichts zu
tuen ist. Und dann ruft man make steak auf und bekommt wieder gesagt,
dass nichts zu tuen ist (was will man an einem Shellscript compilieren?)
und dann ruft man make steak-install auf.
> Wer will den Pakete ;-)))
Die Masse der Leute und Pakete sind auch besser.
> Echte M=E4nner kompilieren die Programme mit der Hand!=20
...und kriechen regelm=E4=DFig durch die Verzeichnisse und r=E4umen auf. =
Aber
das ist eben nur was f=FCr echte M=E4nner(tm).
J=F6rg.
|
|
From: Razi Lotfi-T. <raz...@we...> - 2002-09-12 00:41:27
|
Am Donnerstag, 12. September 2002 01:13 schrieben Sie:
> Razi Lotfi-Tabrizi <raz...@we...> wrote:
>
> > Bitte versteht mich nicht falsch!
> > """""""""""""""""""""""""""""""""""
> > Ich will nicht damit sagen, daß ich Steak für tot erklären möchte.
>
> Doch würde ich. Bei großen Firmen würde man das Fussion nennen :-)
Ja, Nein. Ich werde weiter das Programm (falls ich Zeit habe) pflegen.
Aus dem Grund würde ich mich freuen, wenn Du die Änderungen hinsichlich der
Debian-Paket-Kompatibilität realisieren würdest. Wäre nett.
>
> BTW: Frage an Jens, nachdem ich nun weiß, wer du bist, arbeitet magic-dic
> auch mit [ai]spell?
Noch eine Frage Jens: Warum beinhalten Deine Datensätze diese (siehe unten)
Meta-Daten?
Abgemacht!::It's a deal!::de::uk::glob::0::MGDC::OK::0::www::::
Abgeneigtheit {f}::averseness::de::uk::glob::0::MGDC::OK::0::www::::
Abgeordnete {m,f}::delegate::de::uk::glob::0::MGDC::OK::0::www::::
...
Tschüß
Razi
>
>
> -------------------------------------------------------
> In remembrance
> www.osdn.com/911/
> _______________________________________________
> Steak-developer mailing list
> Ste...@li...
> https://lists.sourceforge.net/lists/listinfo/steak-developer
|
|
From: Razi Lotfi-T. <raz...@we...> - 2002-09-12 00:28:17
|
Am Donnerstag, 12. September 2002 00:30 schrieben Sie:
> Razi Lotfi-Tabrizi <raz...@we...> wrote:
> > Du hast wohl eine neue Version des Datensatzes, oder?
>
> >
> > Finde ich auch OK. Aber schau Dir mal zuert bitte Magic-Dic an.
>
> Gibt es ein Debian-Paket dazu? Wo ist das zu bekommen? (Bin gerade zu
> faul zum suchen :-))
Hast Du es gefunden :-)
> >
> > Vielleicht kann uns dazu Jens mehr sagen.
>
> Wer ist Jens?
OK, ich habe die Emails nicht so ganz sortiert geschickt gehabt ;-)))
>
> >> 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!
>
> make würde ich so und so nehmen. Ich könnte mir ein Leben ohne make
> garnicht vorstellen :-)
Ich glaube, ich komme um diese Automake und Autoconfigure nicht mehr herum.
Ich muß mir die Sache selber anschauen. Leider habe ich wenig Zeit und keine
Lust dazu ;-( Aber es muß wohl sein! Mal sehen, ob ich in den nächsten Tagen
etwas dazu bei uns in der Bibliothek finde (ja, ich bin immer noch ein
Buch-Mensch).
>
> >> 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.
>
> Nein, das geht nicht. Die Pakete enthalten ja alle kompilierte Programme
> und ich muss das Paket schon vollständig machen, damit es bei dem geht,
> der alles will und alles hat. Und den kann ich aber zur Laufzeit nicht
> von dem Unterscheiden, der alles will, aber nicht alles hat.
Wer will den Pakete ;-)))
Echte Männer kompilieren die Programme mit der Hand!
RPM und Debian-Pakete sind nur für Weicheier! :-))
> >> > 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?
>
> Das ist kein Programm sondern ein Paket, wie rpm unter SuSE.
Verstehe. Der Name "trans-..." war ein wenig irritierend!
Razi
|
|
From: Joerg S. <jo...@al...> - 2002-09-11 23:15:30
|
Razi Lotfi-Tabrizi <raz...@we...> wrote: > Hi, >=20 > Der Grund: Ich bin der Meinung, da=DF bevor man etwas neues entwickeln = m=F6chte=20 > (die meisten =C4nderungen, die wir realisieren m=F6chten, kommen eine=20 > Neu-Entwicklung des Programm gleich),=20 > sollte man sich ein wenig umschauen, und sich mit den bestehenden Proje= kten=20 > und Programmen der anderen Entwickler zuerst auseinandersetzen.=20 Richtige Einstellung. > Die Frage, die ich mir nach dem Testen des Magic-Dic stelle, ist: > Ist es =FCberhaupt notwendig Steak umzuschreiben? W=E4re eine Reimpleme= ntierung=20 > =FCberhaupt sinnvoll? Nein, wenn es so ist, wie du beschrieben hast, w=FCrden wir das Rad neu erfinden und das ist verschwendete Zeit und Kraft. > All die Eigenschaften, die wir erreichen k=F6nnten, sind bereits in Mag= ic-Dic=20 > implementiert. Oder =FCbersehe ich etwas?=20 > Aber falls das stimmen sollte, warum sollten wir ein vollkommen neues=20 > Programm entwickeln?=20 > Ich finde das Programm Magic-Dic schon sehr weit fortgeschritten. Ich b= in der=20 > Meinung, da=DF wir unsere Kr=E4fte anstatt auf eine Reimplementierung a= uf die=20 > Erweiterung und Pflege des Magic-Dic konzentrieren sollten. Echt gute Einstellung. Sowas w=FCrde ich mir bei vielen Projekten w=FCnsc= hen. > Bitte versteht mich nicht falsch!=20 > """"""""""""""""""""""""""""""""""" > Ich will nicht damit sagen, da=DF ich Steak f=FCr tot erkl=E4ren m=F6ch= te. Doch w=FCrde ich. Bei gro=DFen Firmen w=FCrde man das Fussion nennen :-) BTW: Frage an Jens, nachdem ich nun wei=DF, wer du bist, arbeitet magic-d= ic auch mit [ai]spell? |
|
From: Joerg S. <jo...@al...> - 2002-09-11 23:15:25
|
Razi Lotfi-Tabrizi <raz...@we...> wrote:
> Du hast wohl eine neue Version des Datensatzes, oder?
Keine Ahnung.
$ dpkg -l trans-de-en
||/ Name Version Beschreibung
+++-=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D-=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D-=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
ii trans-de-en 1.2-1 A German-English translation dictionary
>> > Au=DFerdem habe ich das Gef=FChl (bin ich mir nicht sicher, denn ich=
kenne
>> > mich mit Perl nicht gut aus), da=DF die Such-Routine bei der Bash-Ve=
rsion
>> > schneller ist. Das liegt einfach daran, da=DF die Bash-Version "grep=
"
>> > verwendet.
>>
>> Ja und das wird auch nie anders. An Perl h=E4ngt noch so ein Schwanz d=
ran,
>> das kann nie so gut werden, wie ein hochoptimiertes grep.
>=20
> Wei=DFt Du, ob agrep f=FCr Perl gibt?
Was ist an agrep soviel anders als an grep?
>> Ich w=FCrde sagen, mit Indizes kann man nicht arbeiten. Einmal, weil m=
an
>> auch Teilworte und Wortgruppen sucht und das andere Problem ist. was w=
ill
>> 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=
als
>> Datenbasis.
>=20
> Das sehe ich auch so. Aber in einer Index-Datei (siehe Glimpse) kann ma=
n auch=20
> nach reg. Ausdr=FCcke suchen. Wie, wei=DF ich auch nicht! Aber ich kenn=
e mich mit=20
> Glimpse auch nicht so gut aus.
Ich kann es auch nicht sagen und DBen hatten wir noch nicht im Studium
und ehrlich gesagt, wollte ich mich auch nicht damit besch=E4ftigen. Ist
hier jemand bzw. kennst du jemand, der uns das sagen k=F6nnte, wie man
sowas am D=FCmmsten macht?
Aber das w=FCrde ich dann mit in die Version von unicode packen ;-) (s.u.=
)
>> 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 e=
ben
>> alss Shellscript implementiert ist, aber nur die Funktionen bietet, di=
e
>> er kann.
>=20
> Finde ich auch OK. Aber schau Dir mal zuert bitte Magic-Dic an.
Gibt es ein Debian-Paket dazu? Wo ist das zu bekommen? (Bin gerade zu
faul zum suchen :-))
>> >> > 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=E4hrend" oder "waehrend" sucht.
>=20
> Das hat damit zutun, da=DF viele Leute (z.B. bei den Email) sich eher a=
n=20
> ASCII-7 halten und dadruch keine =DF oder Umlaute bei den deutschen Tex=
ten=20
> verwenden.
W=FCrde es dann nicht auch reichen, wenn man das als Option stellt? Sowas
wie --expand-letters.
>> Nein, ich sehe das als eine unerw=FCnschte Funktionalit=E4t an. Wenn i=
ch nach
>> dem Wort wei=DF (von wissen) suche, bekomme ich viele viele Ergebnisse=
, die
>> nicht dahin geh=F6ren.=20
> steak -d -nowait wei=DF
> --------------------------------------------------
> Deutsch -> English
> 1 ) wei=DF :=3D=3D knows
> 2 ) wei=DF :=3D=3D whitely
> [...]
> Welche Ergebnisse geh=F6ren nicht darein?
Keine. Ich bin von Teilwortsuche ausgegangen und da habe ich dann
weissagen, Weissager,...
>> > Die Frage, die ich mir aber stelle ist, welche Vorteile (abgesehen v=
on
>> > eine bequeme und agbeschlossen abgerundete Werkzeugmenge) bietet Per=
l,
>> > die Shell-Skript nicht bietet?
>>
>=20
>> In der Shell gibt ees zwar Arrays, aber die sind nicht gerade das gelb=
e
>> 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")
>=20
> Vielleicht kann uns dazu Jens mehr sagen.
Wer ist Jens?
> Ja, das wei=DF ich auch! Leider. Es kann aber sein, da=DF agrep UNICODE=
=20
> unterst=FCtzt.
Auf den ersten Blick w=FCrde ich bei der dpkg-Beschreibung =BBnein=AB sag=
en.
>> Wie soll das gehen? Hast du schonmal ein funktionierendes unicode Syst=
em
>> gesehen? Ich wollte letztends die Console auf unicode umstellen, aber
>> welche Shell unterst=FCtzt das? :-((
>=20
> Bei DICT (kombiniert mit Mozilla 7.0 als Client) habe ich es ausprobier=
t. Es=20
> 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=20
> schaffe.
Viel Gl=FCck!
>> Kannst du mir mal bitte, interessenhalber, erkl=E4ren, wozu
>> auto{make,config} gut sind? Was machen diese lustigen Programme?
>=20
> Es ist bei der Installation der Unix-Software ist es fast ein Standard,=
=20
> configure und make zu verwenden. Es w=E4re nicht schlecht, wenn das Ste=
ak sich=20
> auch daran halten k=F6nnte. Ist aber auch nicht so wichtig!
make w=FCrde ich so und so nehmen. Ich k=F6nnte mir ein Leben ohne make
garnicht vorstellen :-)
>> Ich kann dieses Programm nicht mitnehmen. Denn wenn ich es mit aufnehm=
e,
>> muss ich in die Dependencies xlib schreiben und das ist wieder ein rie=
sen
>> Klotz. Das Problem ist, dass das Paket nicht vollkommen funktionst=FCc=
htig
>> 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=
aber
>> selbst printbuffer mit, dann ist es immer installiert, muss aber nicht
>> funktionieren, falls keine xlibs da sind. Die einzigste Chance, die ic=
h
>> sehe, printbuffer arbeitet mit dlopen und pr=FCft, ob xlibs da sind, w=
enn
>> ja l=E4dt es diese, wenn nein endet es in einem definierten Zustand (w=
as
>> bei den dyn. linken nicht m=F6glicht ist)
>=20
> Das k=F6nnte man doch in der Configure-Routine herausfinden, ob xlib=20
> installiert ist oder nicht.
Nein, das geht nicht. Die Pakete enthalten ja alle kompilierte Programme
und ich muss das Paket schon vollst=E4ndig machen, damit es bei dem geht,
der alles will und alles hat. Und den kann ich aber zur Laufzeit nicht
von dem Unterscheiden, der alles will, aber nicht alles hat.
>> > 10) Den Datensatz vielleicht vollkommen von dem Programm trennen und
>> > bei einem anderen separaten CVS-Server integrieren!
>>
>> %-) Wie jetzt, das verstehe ich nicht ganz.
>=20
> Siehe freedict.de
Mach ich.
>> > 11) Das Programm "Steak/Datensatz/datenbankaktualisieren.sh"
>> > modifizieren, so da=DF es auch automatisch den aktuellen Datensatz v=
on
>> > einer CVS-Server holen 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. Datenba=
nk
>> bietet. Was will man mehr?
>=20
> Was ist das f=FCr ein Programm? Gibt es auch allgemein f=FCr Linux?
Das ist kein Programm sondern ein Paket, wie rpm unter SuSE. Wenn es eine
neue DB gibt, macht der Maintainer ein neues Paket und ich erhalte beim
n=E4chsten Update eine neue Datei /usr/.../de-en. Die ist genau das, was
von Frank Richter unter http://dict.tu-chemnitz.de/ bereitgestellt wird.
Ich w=FCrde so und so sagen, dass steak keine W=F6rterbuchdatei mit liefe=
rt
und halt nur Links auf die freedict.de und dict.tu-c... vorschl=E4gt. Man
muss halt nur zusehen, dass steak mit allen B=FCchern arbeiten kann.
> Warum Abh=E4ngigkeiten?
> Ja, warum nicht! Mann nicht beispielsweise Teile von grep!
Naja, das ginge auch, einfach Code aus grep kopieren. Was ich aber meinte
war, eine Bibliothek von jemand anders zu verwenden. Zum Beispiel
"librx1g - GNU Posix Basic Regular Expression language library." Steak
ist dann gegen diese Lib gelinkt.
> Das hei=DF aber nicht, da=DF man dann Unicode nie mehr verwendet! Oder =
glaubst=20
> Du, da=DF wenn Unicode sich durchsetzt, ASCII keine Verwendung finden=20
> wird?=20
Keine Ahnung, ich glaube nichtmal, dass der 32-Bit-Code kommt. Ich w=FCrd=
e
mich aber im Moment noch nicht um unicode sorgen. Erst wenn das
Programm steht und wiedermal jemand Langeweile hat.
|
|
From: Joerg S. <jo...@al...> - 2002-09-11 23:15:22
|
Razi Lotfi-Tabrizi <raz...@we...> wrote: > Am Samstag, 7. September 2002 13:56 schrieben Sie: >> Erik Sittmann schrieb : >> > Hallo, >> > >> > erg=E4nzend zu Razi's =DCberlegungen bez. *Datenbank* m=F6chte ich >> > erw=E4hnen, 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=F6glich auch von C/C++ auf die "Datenbank" zugreifen >> > zu k=F6nnen "DBFile" ist recht performant, kommt auch mit grossen >> > Datenmengen gut zurecht, und die Lernkurve strebt gegen Null. >> >> Ich w=FCrde keine DB daraus machen, schon mit aus dem Grunde, weil man= sich >> da auf ein System festlegt. Ein Text kann in Python, Perl, grep, C, >> C++,... gelesen werden. >=20 > Warum denn festlegen??? Ich dachte es gibt gewisse Standards, mit deren= Hilfe=20 > man mit den meisten DBs kommunizieren kann? a) Das was wir brauchen, ist keine Standard-DB, und b) von Datenbanken gibt es auch gen=FCgend Standards. Frei nach dem Motto "Standards are wonderful. Everyone should have one." |
|
From: Joerg S. <jo...@al...> - 2002-09-11 23:15:19
|
Razi Lotfi-Tabrizi <raz...@we...> wrote: > Am Sonntag, 8. September 2002 13:37 schrieben Sie: >> Fehlgeleitet ist bei mir zum Beispiel ifupdown (ein Paket bei Debian, >> aber auch bei sf.net zu haben). Das Programm ist in C geschrieben und >> macht nicht mehr als die Arbeit eines Shellscripts.=20 >> Es wird der Output >> von ifconfig geparsed, ifconfig wieder mit den richtigen Parametern >> aufgerufen, eine Datei ausgeleseen,... Das sind f=FCr mich alles Dinge= , die >> ein Shellscript wesentlich flexibler und sauberer kann als ein C >> Programm.=20 >=20 > Ja und? Ich verstehe nicht was die Leute gegen sowas haben? Ein Shell m= acht=20 > auch fast das gleiche wie ein Programm! Was ist der Unterschied, wenn = man=20 > ifconfig von einem C-Programm oder von einem Shell-Skript aus aufruft. = Nicht=20 > so viel! Wenn ein Entwickler mit C besser zu recht kommt, dann bitte sc= h=F6n! Ja, aber f=FCr C gibt es den ANSI-Standard. Damit l=E4uft ein Programm au= f jeder Plattform, die einen ansi-Compiler hat. Aber mit ansi-Mitteln kannst du IMHO sowas wie ifconfig nicht schreiben. Hei=DFt also du nimmst den n=E4chst gr=F6=DFeren Standard POSIX und wenn es damit immer noch nic= ht geht,... Man sollte IMO f=FCr eine Aufgabe immer die angemessenen Mittel w=E4hlen. Eben f=FCr ein kleines C-Programm kein C++. BTW: Ich habe jetzt herausgefunden, wie man ein C++-Programm ohne die Abh=E4ngigkeit zur libc= ++ erstellt. Man kompiliert es mit -fno-rtti -fno-exceptions. Und dann sollte man, das hat der ifconfig-Entwickler IMO nicht getan, auch noch daran denken, dass vielleicht andere Leute des Programm lesen wollen. Und da liest sich doch ein Shell-Script sch=F6ner als ein C-Progr= amm. > Der Umgang mit den Shell-Skripte ist nicht so einfach. Die Arbeit mit A= WK,=20 > SED und Co ist nicht so einfach. Bei Perl und Python mu=DF man viele Sa= chen=20 > installieren. Also C/C++ finde ich sch=F6n sehr sinnvoll, wenn ein Skri= pt=20 > anf=E4ngt kompiliziert und un=FCbersichtlich zu werden. Aber das ist al= les reine=20 > Geschmacksache! C, C++ und Java sind f=FCr mich keine Sprachen, mit denen ich mal schnell etwas schreibe. Da muss es schon etwas gr=F6=DFeres sein. Perl wenn es ma= l ein etwas anspruchsvolles Miniprogramm wird und ein Shellscript nehme ich =FCber all da, wo es eben nur ein Script seinen soll. Nat=FCrlich sind da= bei auch mit die Vor- und Nachteile der ganzen Sprachen zu ber=FCcksichtigen. >> Wenn wir so =FCber Geschwindigkeit nachdenken, dann ist eine DB, wie s= ie im >> Moment ist, total falsch. Aber ich w=FCrde das nicht =E4ndern und lieb= er eine >> abgespeckte Shell-version machen, die halt nur eine W=F6rterbuch durch= sucht >> und nicht alle oder die halt einige andere Features nicht hat.=20 >=20 > Bei einem kleinen Programm, wie Steak, finde ich es auch sinnvoller, we= nn man=20 > Skripte verwendet. Aber wenn solch ein Programm gr=F6=DFer wird (siehe=20 > Magic-Dic), kann man auch =FCber C/C++ nachdenken. Ich sehe da einfach nicht die Vorteile. Man implementiert alles, blo=DF zwei Stufen tiefer, und wenn man es nicht mit ISO-C++ schafft oder andere libs verwenden muss, verliehrt man sogar (oder u.U.) die Portalilit=E4t. |
|
From: Razi Lotfi-T. <raz...@we...> - 2002-09-11 20:09:26
|
Am Samstag, 7. September 2002 13:56 schrieben Sie: > Erik Sittmann schrieb : > > 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. > > Ich würde keine DB daraus machen, schon mit aus dem Grunde, weil man sich > da auf ein System festlegt. Ein Text kann in Python, Perl, grep, C, > C++,... gelesen werden. > Warum denn festlegen??? Ich dachte es gibt gewisse Standards, mit deren Hilfe man mit den meisten DBs kommunizieren kann? |
|
From: Razi Lotfi-T. <raz...@we...> - 2002-09-11 20:09:24
|
Am Sonntag, 8. September 2002 13:37 schrieben Sie: > Erik Sittmann schrieb : > > Hallo, > > > > nun möchte ich nur noch wissen, was du unter *fehlgeleite* > > ^+t > > Fehlgeleitet ist bei mir zum Beispiel ifupdown (ein Paket bei Debian, > aber auch bei sf.net zu haben). Das Programm ist in C geschrieben und > macht nicht mehr als die Arbeit eines Shellscripts. > Es wird der Output > von ifconfig geparsed, ifconfig wieder mit den richtigen Parametern > aufgerufen, eine Datei ausgeleseen,... Das sind für mich alles Dinge, die > ein Shellscript wesentlich flexibler und sauberer kann als ein C > Programm. Ja und? Ich verstehe nicht was die Leute gegen sowas haben? Ein Shell macht auch fast das gleiche wie ein Programm! Was ist der Unterschied, wenn man ifconfig von einem C-Programm oder von einem Shell-Skript aus aufruft. Nicht so viel! Wenn ein Entwickler mit C besser zu recht kommt, dann bitte schön! Der Umgang mit den Shell-Skripte ist nicht so einfach. Die Arbeit mit AWK, SED und Co ist nicht so einfach. Bei Perl und Python muß man viele Sachen installieren. Also C/C++ finde ich schön sehr sinnvoll, wenn ein Skript anfängt kompiliziert und unübersichtlich zu werden. Aber das ist alles reine Geschmacksache! > Und genauso wäre es, wenn wir ein C/C++-Programm schreiben, > dass grep aufruft oder dass eine externe Biblio. benutzt. Oder wenn test > in Assembler geschrieben wäre. > > Wenn wir so über Geschwindigkeit nachdenken, dann ist eine DB, wie sie im > Moment ist, total falsch. Aber ich würde das nicht ändern und lieber eine > abgespeckte Shell-version machen, die halt nur eine Wörterbuch durchsucht > und nicht alle oder die halt einige andere Features nicht hat. Bei einem kleinen Programm, wie Steak, finde ich es auch sinnvoller, wenn man Skripte verwendet. Aber wenn solch ein Programm größer wird (siehe Magic-Dic), kann man auch über C/C++ nachdenken. Tschüß Razi |
|
From: Razi Lotfi-T. <raz...@we...> - 2002-09-11 20:06:13
|
Hi, zuerst möchte ich einen neuen Mitglied, Jens Röder, in dieser Runde begrüßen. Jens ist der Entwickler des Programms "Magic-Dic". Ich kenne ihm vom früheren Email-Verkehr. Mehr zu seinem Programm werde ich aber später noch etwas schreiben. Ich wollte mich eigentlich früher melden. Aber bevor ich diese Email schicken wollte, wollte ich mir einige Wörterbuch-Projekte im Internet genauer anschauen. Der Grund: Ich bin der Meinung, daß bevor man etwas neues entwickeln möchte (die meisten Änderungen, die wir realisieren möchten, kommen eine Neu-Entwicklung des Programm gleich), sollte man sich ein wenig umschauen, und sich mit den bestehenden Projekten und Programmen der anderen Entwickler zuerst auseinandersetzen. Dies lernt man sehr schnell, wenn man an eine Diplomarbeit gearbeitet hat ;-)) Als ich mit Steak anfing, gab es im Internet nur DICT als GPL bzw. überhaupt als freies Wörterbuch-Programm. Inzwischen gibt es viele andere Programme. Nicht nur für deutsche Sprache, sonder auch für die Anderen wie beispielsweise für Französisch bzw. Russisch. Ich habe mir am Wochenende viele Programme und Wörterbücher angeschaut. Das ist das Ergebnis meiner Suche: Kommen wir zuerst zu den freien Wörterbüchern: 1) The Internet Dictionary Project: (siehe http://www.june29.com/IDP/) Die Datensätze sind frei (ich glaube aber nicht unter GPL). Die Datensätze sind aber nicht so groß. 2) Der Datensatz von Frank Richter, den ich auch verwende. Dieser Datensatz ist (meiner Meinung nach) der beste freie (GPL) Datensatz für DE-ENG. Sehr umfangreich. 3) FreeDict - for free bilingual dictionaries (siehe http://www.freedict.de/) Diese Seite bieten viele Datensätze. Die Idee finde, die hinter diese Seite steht, finde ich sehr gut. Alle Datensätze sind unter GPL und sind separat unter CVS-Server untergebracht. Der Datensatz für die Deutsch-Englisch basiert auch auf den Datensatz von F.Richer, aber der Datensatz ist sehr viel kleiner als der ursprüngliche Datensatz! (Komisch verstehe ich nicht so ganz) Außerdem sind die Wörterbücher nur in eine Richtung definiert. Was ich auch ein wenig merkwürdig finde. (Das hat wohl (schätze ich mal) mit der Phonetik zu tun) z.B. (Ausgaben) einschrÃ?nken [ausgaË~PbÉ~YnainÊ~CrÉ~[Å~KkÉ~Yn] to cut down (Baum) fÃ?llen [baumfÉ~[lÉ~Yn] to cut down Ich kann Euch auf jeden Fall empfehlen, die Seite Euch anzuschauen. Kommen wir aber zu den wichtigsten freien Wörterbuch-Ansätze im Internet: Es gibt viele freie Wörterbuch-Projekte für Linux. Mein Hauptaugenmerk richtet sich aber bei den unten beschriebenen Projekte nur auf die, die einen interessanten und innovativen Ansatz verfolgten und außerdem frei sind (ich hoffe, daß ich kein weiteres wichtiges Projekt ausgelassen habe). Es gibt zwar Programme, die beispielsweise nur für Russisch implementiert würden, diese lassen ich schon bei Seite. Außerdem gibt es auch Programme, die nicht freie Datensätze (wie beispielsweise, die von Babylon) verwenden. Diese habe ich mir auch näher angeschaut, aber die kann man auch getrostest vernachlässigen. Es gibt beispielsweise Programme, die mit den Datensätzen von Babylon arbeiten können; dieses können aber lediglich nur mit den alten Datensätzen von Babylon arbeiten. Neue Datensätze von Babylon sind verschlüsselt, damit die freien Programme deren Datensätze nicht verwenden können :-(. Aber so ist es, wenn man sich von einen solchen Datensatz abhängig macht. Zuerst aber etwas im Vorfeld zu "Glimpse" (http://webglimpse.org/). Dies ist ein sehr gutes Programm, mit dessen Hilfe man eine Datei indexieren kann. Ich weiß nicht wie, aber mit dessen Hilfe, kann man sogar in einer Datei nach regulären Ausdrücken suchen (mit agrep). Im Gegensatz zu dem Grep gibt es bei agrep eine Beschränkung, die es sich um die Länge der regulären Ausdrücke bezieht. Ich glaube, daß für Perl sowas bzw. die entsprechenden Klassen und Implementierung für glimpse gibt (Jörg weißt Du mehr darüber?) Aber zu den Projekten: 1) DICT (http://www.dict.org) "DICT" sollte meisten von Euch bekannt sein. Er arbeitet auf Client-Server-Prinzip. Das ganze ist sogar in einem RFC beschrieben. Es gibt viele Server- und Client-Implementierungen. Ich habe zur Testzwecke einen Server geladen. Der Server, den ich verwendete, heißt "jDictd" (siehe http://www.informatik.uni-leipzig.de/~duc/Java/JDictd/) und ist in Java implementiert. Das Programm ist wirklich nicht schlecht: Man kann neben ASCII auch Unicode (UTF8) verwenden. Es ist nicht nur auf die Wörterbücher beschränkt, sondern kann man allgemein Lexika usw. verwenden. Das Programm kann mit den Datensätze umgehen, die man bei freedict erhält. Dieses Programm ist auch Index-orientiert, aber soweit ich es verstanden habe, kann man nicht nach regulären Ausdrücke suchen. Ich glaube aber, daß diese Eigenschaft, ob nach regulären Ausdrücke gesucht werden darf oder nicht, nicht unbedingt in RFC vorgeschrieben ist, sondern lediglich den Entwicklern der Servern überlassen (ich habe aber den RFC nicht studiert ;-)). Auf diesen Server kann man über ein Konsole-Programm, das ebenfalls bei dem Programm dabei ist zugreifen. Man kann aber auch über einen HTTP-fähigen Client (beispielsweise über Browser) oder andere DICT-Clients (ich habe auch kdict probiert) zugreifen. Im großen und ganzen ein sehr durchdachtes Konzept 2) jDictionary (http://jdictionary.info) jDictionary ist in Java implementiert. Das ist ein sehr interessante Ansatz, weil das ganze Programm Plugin-basiert arbeitet. Das Programm (selbst) bietet lediglich eine Umgebung für Wörterbücher usw. Neue Sprachen werden als Plugin geladen. Dies ist aber sehr anwenderfreundlich implementiert: die Plugins werden vom Programm aus von der (beispielsweise) Homepage heruntergeladen. Soweit ich es verstehe, bringen die Plugins nicht nur einen Datensatz für eine Sprache (beispielsweise DE-EN) mit, sondern auch die entsprechenden Methoden zur Suche (falls nötig beispielsweise auch reguläre Ausdrücke), Hilfe usw. mit. Ein recht anwenderfreundliche und interessanter Ansatz. Leider ist das Programm sehr langsam und ressourcenhungrig (kein wunder: Java und GUI) Außerdem ist man auf die GUI angewiesen. Es gibt leider keine Console-Version des Programms. Das ganze steht unter LGPL. 3) UniDict (http://www.ping.uio.no/~ovehk/unidict/) Dieses Programm verwendet eine Datenbank. Hierbei werden die Daten in einem mySQL-server gespeichert. Hier einige Zitate aus der Seite: "A client application using the wxWindows C++ application framework connects to the database and downloads words, word attributes, word translations, language attributes, and inflection scripts (including irregular word database) as necessary, to provide the user with anything he/she needs to understand and use any language. A Python interpreter embedded in the client application will execute the scripts in order to perform any conceivable inflection, analysis, and translation tasks. Any user is empowered to upload his/her own language data to the central database; creating, changing, and deleting word definitions, language definitions, inflection scripts, and so on. " Dieses Projekt befindet sich aber noch in Anfangsstadium. Dieses Projekt unterschützt wie die bisher angesprochene anderen Projekte auch UniCode (UTF8) 4) Magic-Dic (http://magic-dic.homeunix.net/) Dieses Programm hatte ich bereits vor einigen Tagen in einer früheren Email erwähnt gehabt. Magic-Dic ist ein Programm, daß von Prinzip her Steak am nächsten steht. Das Programm basiert nicht auf Client-Server-Prinzip und verwendet auch keine Datenbank. Sie ist eine Sammlung von Shell-Skripten. Dieses Programm bietet bereits die meisten Features, die wir implementieren wollten: - Es kann (seit der neuesten Version) auch mit Unicode umgehen. - Es unterstützt bereits mehrere Sprachen - Es ist sehr schnell - Man darf auch lokale Datensätze haben. - Die Verbesserungen hinsichtlich der Datensätze kann man leicht an die Seite des Programms geschickt werden. - Viele weitere Features, die man auf der Homepage des Programm lesen kann.:-) Ich kann Euch empfehlen, dieses Programm herunter zu laden und zu testen. Die Homepage des Programms beinhaltet reichlich Informationen über das Programm. Außerdem kann zu dem Programm unsere neuer Mitglied mehr erzählen. Ein Kritik muß ich bezüglich des Programms trotzdem los werden: Die Farben der Homepage sind (besonders dieses Hintergrund-Grafik) ungünstig gewählt worden. Man bekommt einfach keine Lust die tollen Infos zu lesen ;-) (OK, ich weiß, daß meine Seite auch einfach beschissen aussieht, aber wir reden gerade nicht über meine Seite :-) ) Die Frage, die ich mir nach dem Testen des Magic-Dic stelle, ist: Ist es überhaupt notwendig Steak umzuschreiben? Wäre eine Reimplementierung überhaupt sinnvoll? Steak ist speziell für die Eigenheiten der deutschen Sprache abgeschnitten und ist außerdem (dank grep) sehr schnell. Warum also eine Reimplementierung in Perl oder Python? Welche Vorteile hat man durch Perl, die man bei der Shell-Implementierung von Magic-Dic nicht hat? All die Eigenschaften, die wir erreichen könnten, sind bereits in Magic-Dic implementiert. Oder übersehe ich etwas? Aber falls das stimmen sollte, warum sollten wir ein vollkommen neues Programm entwickeln? Ich finde das Programm Magic-Dic schon sehr weit fortgeschritten. Ich bin der Meinung, daß wir unsere Kräfte anstatt auf eine Reimplementierung auf die Erweiterung und Pflege des Magic-Dic konzentrieren sollten. Bitte versteht mich nicht falsch! """"""""""""""""""""""""""""""""""" Ich will nicht damit sagen, daß ich Steak für tot erklären möchte. Wie bereits erwähnt, ist Steak klein, schnell und außerdem sehr auf die deutsche Sprache abgeschnitten. Ich möchte viele der Änderungen, die ich in der letzten Email angesprochen hatte, vornehmen, aber nicht es nicht mehr auf die Unterstützung andere Sprachen erweitern. Die Punkte, die ich bei Steak immer noch geändert sehen würden, sind: 1) Zusätzlich zum Standard-Datensatz auch -- falls vorhanden -- lokale User-gebundene Datensätze (in $HOME) nach regulären Ausdrücken suchen. 2) 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! 3) Bei der Kompilierung (genauer gesagt bei ./configure) sollte man eine Option habe, mit deren Hilfe man die Kompilierung von "printbuffer" verhindert. 4) Debian-Konforme Installation erlauben. 5) Einige Veränderungen, damit man das Programm auch unter Windows (cygwin) verwenden kann. Weitere Änderungen wie die Unterstützung der anderen Sprachen und Unicode würden Steak zu dem machen, was bereits Magic-Dic ist. Ich würde mich sehr freuen, wenn Ihr mir helfen könntet, daß ich einige der oben genannten Erweiterungen realisieren kann. Was meint Ihr denn dazu? Lieber Jörg, ich habe Deine neue Version ausprobiert. Sauber! Danke. Jörg schau Dir mal auch auf jeden Fall Magic-Dic an. Sag mir was Du dazu meinst. Bis dann Razi Am Sonntag, 8. September 2002 13:37 schrieben Sie: > Erik Sittmann schrieb : > > Hallo, > > > > nun möchte ich nur noch wissen, was du unter *fehlgeleite* > > ^+t > > Fehlgeleitet ist bei mir zum Beispiel ifupdown (ein Paket bei Debian, > aber auch bei sf.net zu haben). Das Programm ist in C geschrieben und > macht nicht mehr als die Arbeit eines Shellscripts. Es wird der Output > von ifconfig geparsed, ifconfig wieder mit den richtigen Parametern > aufgerufen, eine Datei ausgeleseen,... Das sind für mich alles Dinge, die > ein Shellscript wesentlich flexibler und sauberer kann als ein C > Programm. Und genauso wäre es, wenn wir ein C/C++-Programm schreiben, > dass grep aufruft oder dass eine externe Biblio. benutzt. Oder wenn test > in Assembler geschrieben wäre. > > Wenn wir so über Geschwindigkeit nachdenken, dann ist eine DB, wie sie im > Moment ist, total falsch. Aber ich würde das nicht ändern und lieber eine > abgespeckte Shell-version machen, die halt nur eine Wörterbuch durchsucht > und nicht alle oder die halt einige andere Features nicht hat. Wenn man > Komfort haben will, muss man halt auch etwas Zeit opfern. (aber bei >1GHz > Rechnern brauchen wir darüber nicht zu reden.) > > > und *TOFU* verstehst. Ich erwarte das du mannhaft und > > Text Oben Fullquote Unten (Such mal nach vera - Verzeichnis edv > relevanter akronyme; oder einfach apt-get install vera; oder > http://learn.to/quote/) > > Jörg. > > > ------------------------------------------------------- > 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___________________________________________ >____ Steak-developer mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/steak-developer |
|
From: Razi Lotfi-T. <raz...@we...> - 2002-09-11 20:05:45
|
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
|
|
From: Joerg S. <jo...@al...> - 2002-09-08 16:04:42
|
Erik Sittmann schrieb :
> Hallo,
>=20
> nun m=F6chte ich nur noch wissen, was du unter *fehlgeleite*
^+t
Fehlgeleitet ist bei mir zum Beispiel ifupdown (ein Paket bei Debian,
aber auch bei sf.net zu haben). Das Programm ist in C geschrieben und
macht nicht mehr als die Arbeit eines Shellscripts. Es wird der Output
von ifconfig geparsed, ifconfig wieder mit den richtigen Parametern
aufgerufen, eine Datei ausgeleseen,... Das sind f=FCr mich alles Dinge, d=
ie
ein Shellscript wesentlich flexibler und sauberer kann als ein C
Programm. Und genauso w=E4re es, wenn wir ein C/C++-Programm schreiben,
dass grep aufruft oder dass eine externe Biblio. benutzt. Oder wenn test
in Assembler geschrieben w=E4re.
Wenn wir so =FCber Geschwindigkeit nachdenken, dann ist eine DB, wie sie =
im
Moment ist, total falsch. Aber ich w=FCrde das nicht =E4ndern und lieber =
eine
abgespeckte Shell-version machen, die halt nur eine W=F6rterbuch durchsuc=
ht
und nicht alle oder die halt einige andere Features nicht hat. Wenn man
Komfort haben will, muss man halt auch etwas Zeit opfern. (aber bei >1GHz
Rechnern brauchen wir dar=FCber nicht zu reden.)
> und *TOFU* verstehst. Ich erwarte das du mannhaft und
Text Oben Fullquote Unten (Such mal nach vera - Verzeichnis edv
relevanter akronyme; oder einfach apt-get install vera; oder
http://learn.to/quote/)
J=F6rg.
|
|
From: Erik S. <esi...@es...> - 2002-09-07 16:50:51
|
Hallo, nun möchte ich nur noch wissen, was du unter *fehlgeleite* und *TOFU* verstehst. Ich erwarte das du mannhaft und ehrlich erklärst was du mit diesen Worten gemeint hast. MfG -Sittmann Erik On Sat, 7 Sep 2002 11:56:04 +0000 (UTC) Joerg Sommer <jo...@al...> wrote: > Erik Sittmann schrieb : > > 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. > > Ich würde keine DB daraus machen, schon mit aus dem Grunde, weil man > sich da auf ein System festlegt. Ein Text kann in Python, Perl, grep, > C, C++,... gelesen werden. > > > 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. > > Von daher kann man nur C/C++ oder die Shell nehmen. Und C/C++ sehe ich > als fehlgeleite an und in der Shell stößt man hier und da immer wieder > an Ecken, die einen einfach nicht so lassen, wie man will. > > Hey. Bitte kein TOFU und schon garnicht in der Größe. > > Jörg. > > > ------------------------------------------------------- > 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 |
|
From: Joerg S. <jo...@al...> - 2002-09-07 16:27:06
|
Erik Sittmann schrieb : > Hallo, >=20 > erg=E4nzend zu Razi's =DCberlegungen bez. *Datenbank* m=F6chte ich > erw=E4hnen, dass bei CPAN ein optionales Package namens=20 > "DBFile" downloadbar ist. Zusammen mit "DBFile::Lock" (Record- > File Locking) basiert es auf der BerkeleyDB und damit ist es > prinzipiell m=F6glich auch von C/C++ auf die "Datenbank" zugreifen > zu k=F6nnen "DBFile" ist recht performant, kommt auch mit grossen > Datenmengen gut zurecht, und die Lernkurve strebt gegen Null. Ich w=FCrde keine DB daraus machen, schon mit aus dem Grunde, weil man si= ch da auf ein System festlegt. Ein Text kann in Python, Perl, grep, C, C++,... gelesen werden. > 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=20 > Perl wirklich eingesetzt werden sollte. Von daher kann man nur C/C++ oder die Shell nehmen. Und C/C++ sehe ich als fehlgeleite an und in der Shell st=F6=DFt man hier und da immer wiede= r an Ecken, die einen einfach nicht so lassen, wie man will. Hey. Bitte kein TOFU und schon garnicht in der Gr=F6=DFe. J=F6rg. |
|
From: Joerg S. <jo...@al...> - 2002-09-07 16:27:01
|
Hier nun mal mein endg=FCltiges Perlprogramm:
#v+
#!/usr/bin/perl -w #T
#
# Copyright (c) 2002 Razi Lotfi-Tabrizi <ra...@cs...>
#
# License: This script is distributed under the terms of version 2
# of the GNU GPL. See the LICENSE file included with the packa=
ge.
#
my $VERSION=3D"1.8.0";
=20
use Getopt::Long;
use strict;
use warnings;
my $xcb=3D"/usr/bin/X11/xcb";
my $xcb_opt=3D"-p 0";
my $use_xbuf=3D0;
my $trans=3D"de-en";
my @dicts=3D (["/usr/share/trans/de-en", "de", "en"],
["/dev/null", "de", "fr"],
[$ENV{"HOME"}."/.en-de", "en", "de"]);
my %LANGS=3D (de =3D> "German",
en =3D> "English",
fr =3D> "French");
my $usage=3D"usage: steak [options] [word]...\n".
"Options:\n".
" --and|--or concatenate the word with \"and\"(default) or =
\"or\"\n".
" --[no]clipboard take the word from the X cut buffer if none is=
given\n".
" at the command line (default: true)\n".
" -i|--[no]ignore search case insensitiv\n".
" -V|--version print version\n".
" --help print this help message\n";
# parse config
# parse options
my $andor=3D1;
my $version=3D0;
my $help=3D0;
my $ignore_case=3D0;
unless ( GetOptions('and' =3D> sub { $andor=3D1; },
'or' =3D> sub { $andor=3D0; },
'clipboard!' =3D> \$use_xbuf,
'i|ignore!' =3D> \$ignore_case,
'trans=3Ds' =3D> \$trans,
'V|version' =3D> \$version,
'help' =3D> \$help) ) {
print($usage);
exit(1);
}
my @words=3D@ARGV;
if ($version) {
print("steak: $VERSION\n");
exit(0);
}
if ($help) {
print($usage);
exit(0);
}
if (@words =3D=3D 0 && $use_xbuf && -x $xcb) {
open(XBUF, "-|", "$xcb $xcb_opt") || die;
@words =3D <XBUF>;
close(XBUF);
}
if (@words =3D=3D 1 && $words[0] eq "-") {
shift(@words);
my $i=3D1;
while (1) {
print "word $i: ";
my $word =3D <>;
last if (! defined $word || $word eq "\n");
push(@words, $word);
++$i;
}
}
die "No words for translation given\n" if (@words =3D=3D 0);
my ($lang1, $lang2) =3D ($trans =3D~ /([[:alpha:]]{2})-([[:alpha:]]{2})/)=
;
my @files;
foreach (@dicts) {
my ($file, $lang_l, $lang_r) =3D @{$_};
next if (! -r $file);
=20
if ($lang1 eq $lang_l && $lang2 eq $lang_r) {
push @files, [ $file, 0 ];
} elsif ($lang1 eq $lang_r && $lang2 eq $lang_l) {
push @files, [ $file, 1 ];
}
}
undef @dicts;
die "No dictionaries found for this language" if ( $#files =3D=3D -1);
print(" --------------------------------------------------\n=
");
print " " foreach (1..(37-length($LANGS{$lang1})));
print "$LANGS{$lang1} -> $LANGS{$lang2}\n";
@words =3D map(quotemeta(), @words);
foreach my $f (@files) {
my ($file, $side) =3D @$f;
my @regexp;
if ($andor) {
if ($side=3D=3D0) { # left side
$_ .=3D ".*::" foreach(@words);
} else { # right side
$_ =3D "::.*$_" foreach(@words);
}
@regexp =3D @words;
} else {
my $help;
if (@words =3D=3D 1) {
$help =3D $words[0];
} else {
$help =3D '('.join('|', @words).')';
}
=09
if ($side=3D=3D0) { # left side
$help .=3D ".*::";
} else { # right side
$help =3D "::.*$help";
}
push(@regexp, $help);
}
open(DICT, "<", $file) || die "Cannot open dictionary file \"$file\":=
$!";
my $check;
foreach (@regexp) {
$check .=3D 'next if ($_ !~ /'.$_.'/'.($ignore_case?'i':'').');';
}
eval('while(<DICT>) {'.
'next if (/^#/);'.
$check.=20
'chomp($_);'.
($side=3D=3D0?
's/^ *(.*) *:: *(.*) *$/$1 :=3D=3D $2/;'
:
's/^ *(.*) *:: *(.*) *$/$2 :=3D=3D $1/;').
'print $_,"\n";'.
'}');
close(DICT) || die "Cannot close file: $!";
}
#v-
|
|
From: Joerg S. <jo...@al...> - 2002-09-07 16:26:56
|
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. |
|
From: Erik S. <esi...@es...> - 2002-09-06 21:42:49
|
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 |
1 message has been excluded from this view by a project administrator.
