*** Protokolldatei gestartet
*** Datum: Mi Dez 3 20:00:30 2008
[Mi Dez 3 2008] [20:00:30] Betreten Sie haben den Kanal #forth-ev betreten (~bernd@ppp-93-104-110-106.dynamic.mnet-online.de).
[Mi Dez 3 2008] [20:09:13] Betreten erwaelde hat den Kanal betreten (-user@p549E8D09.dip0.t-ipconnect.de).
[Mi Dez 3 2008] [20:09:20] <erwaelde> Tag!
[Mi Dez 3 2008] [20:09:42] <MatthiasT_> Oh, ist ja schon richtig voll geworden. Hallole
[Mi Dez 3 2008] [20:10:20] <erwaelde> Hallo Matthias.
[Mi Dez 3 2008] [20:14:42] <MatthiasT_> Die XCHARs sind ja heftig diskutiert worden (dlf)
[Mi Dez 3 2008] [20:16:19] <BerndPaysan> Hallo
[Mi Dez 3 2008] [20:16:32] <BerndPaysan> Ja, mit den Xchars, da ging's hoch her ;-)
[Mi Dez 3 2008] [20:17:00] <MatthiasT_> Aber so richtig ein Ergebnis habe ich nicht entdeckt.
[Mi Dez 3 2008] [20:17:33] <MatthiasT_> Wenngleich ich zugeben muss, der Einwand von Elisabeth ist nicht ohne
[Mi Dez 3 2008] [20:17:40] <BerndPaysan> Insbesondere die kontroverse Frage des Default-Encodings wurde nicht gelöst.
[Mi Dez 3 2008] [20:18:16] <MatthiasT_> Andererseits, auf dem Stack gibts nur Zellen, und die sind wohl allesamt 16bit (oder mehr), das reicht für UTF massig aus
[Mi Dez 3 2008] [20:18:31] <BerndPaysan> 16 Bit reicht für UCS nicht aus.
[Mi Dez 3 2008] [20:18:45] <MatthiasT_> Also braucht man nur ein paar Hooks definieren, die bei den Characterzugriffen (emit, key, c, etc( passend konvertieren
[Mi Dez 3 2008] [20:19:16] <BerndPaysan> Ich glaube, ein xc, habe ich gar nicht definiert - kann man aber noch 'reinpacken.
[Mi Dez 3 2008] [20:20:01] <MatthiasT_> Oder sieht das Modell vor, das man CHaracter auch außerhalb des Stacks bearbeiten /vergleichen können kann?
[Mi Dez 3 2008] [20:20:45] <BerndPaysan> Das Modell sieht das vor.
[Mi Dez 3 2008] [20:20:45] <MatthiasT_> (Die Hook-Idee gefällt mir als generelles Design Pattern, merkt man das?)
[Mi Dez 3 2008] [20:22:09] <MatthiasT_> Also wäre bswp ein DMA Transfer von Blockgerät nach RAM unter Umgehung des Stacks im Rahmen des zulässigen? Wo die VM quasi nur koordiniert
[Mi Dez 3 2008] [20:22:43] <MatthiasT_> Und dabei werden trotzdem die Konvertierungen gemacht?
[Mi Dez 3 2008] [20:22:54] <BerndPaysan> Normalerweise braucht man eigentlich keine Konvertierungen.
[Mi Dez 3 2008] [20:24:02] <BerndPaysan> Ich überlege mir zur Zeit, ob man nicht ein XTYPE braucht, das evtl. für das Terminal die richtige Konvertierung macht.
[Mi Dez 3 2008] [20:24:37] <BerndPaysan> Hintergrund ist, dass man seine Sourcen eigentlich am liebsten immer UTF-8 hat, egal, was der User für eine Locale gesetzt hat.
[Mi Dez 3 2008] [20:25:21] <BerndPaysan> Die meisten Editoren könnten inzwischen UTF-8 automatisch erkennen.
[Mi Dez 3 2008] [20:27:57] <MatthiasT_> Spannender wären Dictionaryeinträge, die man mit Quelltexten unterschiedlicher Codierung (vor allem die "alten" codepage orientierten) bearbeiten kann. Da ist UTF-16 sicher nicht die falscheste Wahl (UTF-32 habe ich grade in der Wikipedia gelesen, wozu das wohl gut sein soll)
[Mi Dez 3 2008] [20:28:25] <BerndPaysan> Alles was nicht ASCII-kopatibel ist, ist in der Praxis unbrauchbar.
[Mi Dez 3 2008] [20:28:46] <BerndPaysan> Ein Forth-System kommt erst mal als ASCII-System hoch.
[Mi Dez 3 2008] [20:28:51] <BerndPaysan> Das ist auch im Standard so definiert.
[Mi Dez 3 2008] [20:30:30] <MatthiasT_> hmm. Dann ist mir der Zweck der xchars noch weniger klar. Oder sind die "nur" entstanden, weil alle Welt den gleichen Fehler wie bei C macht, das ein character auch ein byte umfasst (was schon bei C nicht der Fall ist, wenn man K&R liest)?
[Mi Dez 3 2008] [20:31:26] <BerndPaysan> Die xchars sind für Zeichen variabler Länge gedacht, die aus einzelnen Bytes zusammengesetzt sind, und ASCII-kompatibel sind.
[Mi Dez 3 2008] [20:31:47] <MatthiasT_> Das sind utf-8 chars
[Mi Dez 3 2008] [20:31:59] <BerndPaysan> Bis auf UTF-16 und UTF-32 sind *alle* bisherigen Kodierungen genau so.
[Mi Dez 3 2008] [20:32:11] <BerndPaysan> Also auch Big5/GB für China, JIS für Japan, etc.
[Mi Dez 3 2008] [20:33:05] <MatthiasT_> Also soll ein xchar ein Zeichen repräsentieren. Da auf dem Stack nur Zellen liegen (was der xchar RFD ja nicht ändert), sind da nur Characters mit maximal Zellengröße handlebar
[Mi Dez 3 2008] [20:33:29] <BerndPaysan> Auf dem Stack schon, im Speicher können aber alle Zeichen verarbeitet werden.
[Mi Dez 3 2008] [20:33:38] <MatthiasT_> Ich hätte beim amforth also Probleme, ein 3byte Zeichencode zu verarbeiten
[Mi Dez 3 2008] [20:33:49] <BerndPaysan> Nein, den kann man doch als String verarbeiten.
[Mi Dez 3 2008] [20:33:56] <MatthiasT_> Was im Speicher liegt, entscheidet einzig und allen c@ / c! oder?
[Mi Dez 3 2008] [20:34:28] <BerndPaysan> Letztlich greift man auf Strings mit C@/C! zu, ja.
[Mi Dez 3 2008] [20:34:39] <BerndPaysan> Das sind die "primitive characters"
[Mi Dez 3 2008] [20:34:56] <MatthiasT_> wieso?
[Mi Dez 3 2008] [20:36:14] <MatthiasT_> c@ hinterlässt eine Stackzelle, char+ geht zum nächsten Zeichen (da kann man also durchaus variable Characterlängen im Speicher kaschieren). Ist alles nicht einfach umzusetzen, aber vom Konzept her sehe ich eigentlich keine Probleme
[Mi Dez 3 2008] [20:36:29] <MatthiasT_> emit / key analog
[Mi Dez 3 2008] [20:36:50] <BerndPaysan> Irgendwo braucht man einen Speicherzugriff, der die Daten im Speicher nicht interpretiert.
[Mi Dez 3 2008] [20:36:55] <BerndPaysan> Das machen C@/C!.
[Mi Dez 3 2008] [20:37:05] <BerndPaysan> XC@+/XC!+ interpretieren.
[Mi Dez 3 2008] [20:37:32] <MatthiasT_> wenn ich die Byterepräsentation des Strings sehen will, ja. Ansonsten ist mir das eigentlich völlig egal
[Mi Dez 3 2008] [20:38:12] <BerndPaysan> Bei Forth hat man oft Binärdaten im Speicher.
[Mi Dez 3 2008] [20:38:20] <MatthiasT_> das sind aber keine Strings
[Mi Dez 3 2008] [20:38:38] <BerndPaysan> Also, ich nutze meine String-Library auch ganz frei für Binärdaten.
[Mi Dez 3 2008] [20:38:53] <MatthiasT_> Da wird auch der Hase im Unkraut liegen ;=)
[Mi Dez 3 2008] [20:38:58] <BerndPaysan> Wenn ich ein EEPROM mit einem b16-Code beschreibe, dann lade ich die Datei in einen String.
[Mi Dez 3 2008] [20:39:51] <MatthiasT_> Spricht ja nichts dagegen. Dann muss SOURCE und REFILL passend arbeiten
[Mi Dez 3 2008] [20:41:04] <BerndPaysan> Die Quelle ist erst mal eine Hex-Datei - die wird beim Einlesen byteweise konvertiert.
[Mi Dez 3 2008] [20:41:07] <MatthiasT_> Wenn Du aber Bytefolgen als Strings ansiehst, wird sich das immer beissen. Ist halt eine "gute" alte Tradition, einen String als Folge von Bytes anzusehen, wobei ein byte ein character ist
[Mi Dez 3 2008] [20:41:27] <BerndPaysan> Ja, das möchten eigentlich alle erhalten.
[Mi Dez 3 2008] [20:42:03] <MatthiasT_> Methodisch falsch, aber zu tief in den Köpfen verankert, um es noch ändern zu können.......
[Mi Dez 3 2008] [20:42:44] <BerndPaysan> Ich finde das methodisch gar nicht so falsch.
[Mi Dez 3 2008] [20:43:19] <BerndPaysan> In der theoretischen Informatik geht man davon aus, dass es Alphabete und Zeichenfolgen gibt.
[Mi Dez 3 2008] [20:43:29] <BerndPaysan> Damit kann man den Computer universell beschreiben.
[Mi Dez 3 2008] [20:43:34] <MatthiasT_> Was? Das man sich mit der byterepräsentation einer Zeichenfolge herumschlagen muss?
[Mi Dez 3 2008] [20:43:49] <BerndPaysan> Ein "Alphabet" ist kein Zeichen.
[Mi Dez 3 2008] [20:43:59] <BerndPaysan> Es ist nur eine Menge von möglichen Zuständen einer Zelle.
[Mi Dez 3 2008] [20:44:16] <BerndPaysan> Und zum Alphabet wird es durch die Ordnung, die über diese Menge gebildet wird ;-).
[Mi Dez 3 2008] [20:44:52] <BerndPaysan> Der Rest ist Sache der Interpretation durch das Programm.
[Mi Dez 3 2008] [20:45:57] <MatthiasT_> Na, dann macht mal. Wenn die xchars mehr als 16bit groß werden (müssen|können) sind die ohnehin für mich ziemlich uninteressant ;=)
[Mi Dez 3 2008] [20:46:09] <BerndPaysan> Wenn das Programm entscheidet, E4 BD A0 E5 A5 BD als "你好" zu verstehen, dann ist das halt so.
[Mi Dez 3 2008] [20:46:41] <MatthiasT_> Mal davon abgesehen, das das Programm gar nichts entscheidet. Das ist IIRC immer noch der Programmierer ;=))
[Mi Dez 3 2008] [20:47:22] <MatthiasT_> Auch wenn man das oft genug anzweifelt
[Mi Dez 3 2008] [20:47:23] <BerndPaysan> Sobald das Programm einen bedingten Sprung hat, entscheidet es. Deshalb hat Zuse anfangs keine bedingten Sprünge eingebaut ;-)
[Mi Dez 3 2008] [20:59:20] <BerndPaysan> Hat hier jemand eine Meinung, ob man die bisher "character" benannten Bytes im Speicher in pchar umbenennen soll oder nicht?
[Mi Dez 3 2008] [20:59:44] <MatthiasT_> Ich würde sie byte nennen
[Mi Dez 3 2008] [21:00:05] <MatthiasT_> Eben im Unterschied zum character
[Mi Dez 3 2008] [21:00:05] <BerndPaysan> Ja, das genau sind sie aber nicht ;-)
[Mi Dez 3 2008] [21:00:43] <MatthiasT_> Die Umwandlung zwischen dem character und dessen bytefolge (wo auch immer) über hooks machen lassen
[Mi Dez 3 2008] [21:01:12] <BerndPaysan> Der interpretierende Teil der XCHAR-Wörter sind in Gforth Deferred words.
[Mi Dez 3 2008] [21:01:31] <BerndPaysan> In bigFORTH nicht, da gibt's nur zwei mögliche Kodierungen: UTF-8 oder Bytes.
[Mi Dez 3 2008] [21:03:18] <MatthiasT_> in amforth wird das byte so genommen, wie es kommt. Ganz brutal terminal-abhängig
[Mi Dez 3 2008] [21:04:33] Beenden erwaelde hat den Server verlassen ("quit.").
[Mi Dez 3 2008] [21:11:43] <MatthiasT_> Ich "gehe" dann mal.
[Mi Dez 3 2008] [21:11:49] <MatthiasT_> Machs gut
[Mi Dez 3 2008] [21:11:54] Beenden MatthiasT_ hat den Server verlassen (EOF From client).