[Allegro] ucodes

[Thomas Berger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg,

>> darf ich Sie noch einmal an meine Bemerkungen
>> http://sun250.biblio.etc.tu-bs.de/pipermail/allegro/2010-April/031310.html
>>
>> erinnern, ...
> 
> Das ist ein schöner, äußerst gründlicher Text, und wir geben zu, die in
> Rede stehende Datei ucodes.apt viel zu oberflächlich und vorschnell
> verändert zu haben, nachdem ein einzelner Anwender damit Ärger hatte.
> Nur: Ihre Ausführungen sind exegetisch und textkritisch statt
> konstruktiv, und Sie warten anscheinend lieber ab, bis aus Braunschweig
> was kommt, bevor Sie die aktuelle Version installieren. Dabei ist doch
> eine solche Datei kein kultisches Artefakt, kein Grundstein, den erst
> wir und keiner sonst zu legen und zu richten hätten bevor man mit
> dem Bauen anfangen kann. Sie können doch durchaus die neuen Programme
> übernehmen und nur die alte ucodes.apt drinlassen.

... und die alte cat.api

Dass man auch Executables isoliert austauschen kann, ist mir bekannt,
phasenweise passiert das fast taeglich. In anderen Kulturen ist der
Grund dafuer, dass gravierende Bugs gefixt worden waren, bei allegro
muss es andere Gruende haben, da es dort bekanntlich keine B**gs gibt.

"Versionsumstieg" (fuer Datenbanken, die i.W. nach dem A-Schema funktionieren)
bedeutet aber mehr, naemlich alle Dateien etc. aus inst-all irgendwie
zu uebernehmen: Alles haengt bekanntlich mit allem zusammen, d.h.
Verlautbarung Vbx referenziert eine neue y.rtf, das dort beschriebene
Verhalten beruht aber nicht nur auf neuer Funktionalitaet in a99 sondern
auch auf einer geaenderten z.flx

Es ist da aufwendig genug, die verschiedenen Versionen zu vergleichen
und man denkt sich dann manchmal so seinen Teil (siehe die oben zitierte
Anfrage), nun aber eine Formalisierung einfuehren zu muessen, welche
Aenderungen wirklich ernst gemeint sind und welche vielleicht teilweise
wieder rueckgaengig gemacht werden, geht mir zu weit: Wenn Sie etwas
als die einzige aktuell gueltige Allegro-Version ausliefern, muss ich
das als "ernst gemeint" interpretieren, andere Indizien gibt es nicht.


> So geht es nicht, wenn wir langsam mal zu einer OpenSource-Community
> werden wollen. In einer solchen wird nicht ganz oben alles ex cathedra
> entschieden und man fügt sich, da gilt kein "Roma locuta, causa finita",
> und da bleibt man nicht im vorsichtigen Beschreiben von Mißständen
> stecken, da schlägt man klipp und klar konkrete Änderungen vor, da
> liefert man eine neue Datei, in der alles so ist, wie man es für richtig
> befindet. Und wir sind dann die letzten, die konkrete, vernünftige,
> durchdachte Vorschläge nicht in den Standard übernähmen. Das ist doch
> immer schon mal geschehen, aber viel zu selten, weit öfter wird erst
> mal abgewartet statt initiativ zu werden. Schade.

Unter  http://svn.gymel.com/tubscheck/produkt/checkdir/
sehen Sie bei "Messages" die reinen Syntaxfehler in den Standardparametern.

In http://svn.gymel.com/tubscheck/produkt/pardir/
sind alle moeglichen Dateien fehlerkorrigiert.

Ein Weg ist also, die Dateien in checkdir mit denen in pardir zu
vergleichen.


Das SVN-Repository dazu ist
http://svn.gymel.com/repos/allegro/tubs/trunk/
http://svn.gymel.com/viewvc/allegro/tubs/trunk/

An http://svn.gymel.com/viewvc/allegro/tubs/trunk/par/cat.api koennen
Sie sehen, dass dort derzeit 48 Stellen mit "bugfix" markiert sind,
d.h. in den Standardparametern (v29.8) fehlerhaft sind und von mir
unter Parallelfuehrung von "original" und "repariert" korrigiert wurden.
Nach meiner Erinnerung haben Sie sich an diesen fehlerkorrigierten
Versionen vor etwa 15 Jahren ein einziges Mal bedient...

Konkret zu ucodes.apt sind meine Vorschlaege wie folgt:

1. ucodes.apt nicht als Kopie in cat.api fuehren sondern mit
tucodes
   auf die einzige Version zugreifen. Grund: Sonst nicht pflegbar
   (siehe die derzeitigen Divergenzen)

2. ucodes.apt muss konsistenter sein, seit ich nicht mehr so gut
bitshift-Operationen im Kopf rechnen kann, machen mir

 u 202 185 39         weiches Zeichen?
oder
u 195 134 146        LATIN CAPITAL LETTER AE

  ziemliche Muehe, wenn ich die Zeichenposition wissen will.


u 194 174 040 082  REGISTERED SIGN  (R  C2 AE; [00AE] -- &#174
bzw.
u 225 184 143 100 223   LATIN SMALL LETTER D WITH LINE BELOW' (U+1E0F) ḏ

  sind da schon besser. Sind die Zeilen naemlich einheitlich, so koennen
  sie programmatisch ueberarbeitet werden, "225 184 143" und "ḏ"
  lassen sich ja aus U+1E0F berechnen, sogar die Namen sind in den meisten
  Programmiersprachen verfuegbar...
  Ich koennte mir vorstellen, dass es zur Pflege von ucodes.apt eine
  kleine Ausgangstabelle gibt und ein Script, das daraus eine
  Parameterdatei macht. Oder - wenn die Parameterdatei das Original sein
  soll - ein Script, das die Parameterdatei vereinheitlicht und ergaenzt,
  so dass man Aenderungen als "Skizze" vornehmen kann

  [etwas aehnliches gibt es unter
   http://svn.gymel.com/viewvc/allegro/acxt/isbn/trunk/ : Ein Skript, das
   aus einer offizioesen Tabelle von ISBN-Bloecken eine Parameterdatei
   baut, die korrekte Bindestriche in ISBNs einfuegen kann]

3. Hier ist der Knackpunkt, wo ich keine (konkreten) Vorschlaege machen kann:
   Was sollten die juengsten Aenderungen in ucodes.apt eigentlich bewirken.
   Offensichtlich gab es einen Anlass, warum die Funktionalitaet der u-Tabelle
   im Februar auf "001" = Vernichten des Fremdzeichens erweitert wurde. Das
   wurde dann in ucodes eingebaut und dies dann wiederum als Anlass genommen,
   diverse andere Unicode-Zeichen auf recht vage Ersatzdarstellungen abzubilden.
   Es gibt in der Parameterdatei aber keine Hinweise darauf, ob das nun ein
   Strategiewechsel ist (bislang: alle nicht absolut eindeutigen Abbildungen
   durch Erhalt des unicode-Zeichens als &#nnn; dokumentieren, nun: die Zahl
   solcher Faelle mit aller Kraft minimieren), ob den hinzugekommenen
   Zeilen konkrete Daten zugrunde lagen oder systematisch Kombinationen
   aufgezaehlt wurden etc. Mein Vorschlag kann da nur sein, an der *Bedeutung*
   von ucodes.apt nicht zu drehen und hier nur die eindeutigen Umwandlungen
   UTF-8 nach OSTWEST aufzufuehren. Darueber hinausgehende, fallweise
   Maximal-Mappings sollten in einer zusaetzlichen .apt-Datei gesammelt werden
   und nur fallweise dazugeschaltet.

4. Allegro-Parameterdateien (zumindest die von Braunschweig ausgelieferten)
   sind schon seit 20 Jahren Open Source bzw. Public Domain (jeder mag sich
   seine Uebersetzung in unser Recht selber aussuchen). An dieser Stelle
   sind wir faktisch seit ueber 20 Jahren eine "Open Source Community" aber
   ich sehe genau so wie Sie, dass da etwas nicht so recht klappt. Das sollte
   vielleicht einmal breiter diskutiert werden. Aber selbst in einer besseren
   Welt wuerde man nur offensichtliche Fehler korrigieren, oder klar abgegrenzte
   Ergaenzungen als konkreten Code vorschlagen (und dem Entwickler einen "patch"
   schicken, den der maschinell einarbeitet), sobald aber (fuer den Aussen-
   stehenden, vgl. auch 3) im Nebel liegt, was die Strategie ist, kann man
   nur moeglichst vollstaendig alle Probleme analysieren (die konkreten in
   der Ausgangsmail, was Arbeit genug war, die strukturellen hoffe ich oben
   bei 2. angerissen zu haben). Und es gibt natuerlich das ungeschriebene
   Gesetz, dass Verschlimmbesserungen vom Verursacher auszubuegeln sind, und
   zwar prioritaer...

5. ucodes.apt ist keine Belanglosigkeit, sondern ganz eng verzahnt mit der
   Semantik des OSTWEST-Zeichensatzes. Da muss jede Aenderung aeusserst
   durchdacht sein...

viele Gruesse
Thomas Berger

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iJwEAQECAAYFAkwQo5UACgkQYhMlmJ6W47M/DQP+JozKG3GOyQzcwdoSl7ASyqtl
kkueo7uoUQddkoFszIT7okzCKO/XZFcRza/aOOC7XngLUorjmg4j3OWkv4pcqiQZ
OC2D9bTTdBOzM1VPHH4d6VaNU70HzqNB74gxF+drX+K+8BnLhEVyR1IZ+TMABtuB
fiMHDGrm+Rd6XRuYc8g=
=05AN
-----END PGP SIGNATURE-----