[Allegro] Höllenfahrt findet vorerst nicht statt

[Thomas Berger]

Lieber Herr Eversberg,

>> 1. So umrüsten, daß UTF-8 innerhalb A.CFG möglichst weitgehend verwendet
>>      werden kann. Dazu müssen wohl gewisse Modifikationen in a99 sein,
>>      was die Umcodierung angeht. Parameter und Workflow für eine
>>      Migration erstellen bzw. verbessern. Siehe dazu:
>>        http://www.allegro-c.de/unicode//index.htm#meth2
>> Warum diese und nicht die andere Methode?
> Weil Fremddaten i.a.R. UTF-8 (s.u.) sind und damit dann weniger
> Konvertieraufwand entsteht.

o.k. ist fuer die allegro-Interna natuerlich viel aufwendiger.


>> 2. Unterstützende Funktionen (weiter)entwickeln, die erforderlich sind,
>>      um a99 zu ergänzen, wo es mit UTF-8 nicht umgehen kann. Die Eingabe-
>>      felder können nun mal nicht auf Unicode umgerüstet werden!!! Es gibt
>> Sie tun wieder so, als gaebe es auf Windows-Rechnern keine Beispiele
>> von Software mit Eingabefeldern, die mit Unicode arbeitet.
> Nein, ich sage nur, daß es mit dem Programmiersystem, das wir nun mal haben,
> also Visual C++ , nur mit 16bit-Zeichen machbar wäre, aber solche Felder können
> wir in unseren Quellen nicht handhaben und solche Daten nicht in .ALD speichern.
> Falls es Ihnen dennoch gelingen sollte, übernähmen wir das mit Dank und
> Anerkennung.

Was ist "es"? Behaupten Sie gerade, dass es zu schwierig ist, die
Unicode-Unterstuetzung des Betriebssystems zu nutzen und Sie daher
diesen Apparat von Null an lieber selber programmieren? Haben Sie
gelesen, was ich vorhin ueber den Unterschied zwischen Zeichen und
ihrer Repraesentation geschrieben habe? Was meinen Sie mit "Felder"?

Die intern genutzten "Wide-Character"-Datentypen sind ein Kompromiss, weil
die Verarbeitung von Zeichen variabler Speicherlaenge sehr zeitintensiv
ist. Behandeln Sie einfach mal die ganzen Compiler-Warnungen bezueglich
Casting-Problemen, wenn Sie die allegro-Module dann auf 64bit-Systemen
compilieren koennen (und dort funktionieren) haben Sie schon die Haelfte des
Weges zu "intern Unicode" geschafft.


> Nur nebenbei: Unternehmungen wie datahub.io und lod-cloud.net sind gut gemeint,
> aber was die uns interessierenden Daten angeht, noch nicht recht befriedigend.
> (Die berühmte Datenwolke wurde zudem zuletzt Sept. 2011 aktualisiert.) In
> datahub fehlt zudem meist eine Angabe zum Datum der Erstellung der Daten.

Worauf wollen Sie hinaus? Dass die Open-Data-Strategie von VZG oder
TU Braunschweig viel vorbildlicher ist und allen zur Nachahmung
empfohlen wird?

viele Gruesse
Thomas Berger