Änderung im Dateiformat

[greiol]

Micro GC1KGFM
Small GC1HZYR
Regular GC10CXG
Large GCZBT0
Not chosen GC16YKK
Other GC1Q88V
Virtual GCK02P

 

[Engywuck]

Werde ich nachher ausprobieren, wenn ich von der CacheWolf-Anwendung zurückkomme ;-)

Gruß,
E.

 

[Geo-Johnny]

Ich hab das auf Bitte von MiK auf der NB-Website mal angemerkt, damit sich später keiner beschwert wenn es Datenverlust beim Update gibt

Frage eines NB-Fans:
Wird es auch eine entsprechende "Entwarnung" geben, oder zumindest eine kurze Erklärung was man unbedingt vermeiden sollte? Oder läuft es auf eine gänzlich neue Finalversion hinaus?
Ich habe NB r1794 schon am laufen gehabt und es lief soweit alles glatt, allerdings bin ich nach Eurer Warnung wieder auf r1786 mittels internen Datenbackup zurückgegangen.
L.G. - Johnny

 

[MiK]

Ich hoffe, dass diese letzten Fragen innerhalb einer Woche geklärt sind. Danach kann man wohl sicher updaten (aber nicht mehr downgraden). Ich werde mich um eine entsprechende "Entwarnung" kümmern, wenn ich der Meinung bin, dass wir soweit sind.

 

[MiK]

Meine Meinung zur Cachetyp-Kodierung:

1. Wir haben ja schon getrennte Konstanten für OC, GC und CW-Mapping. Dabei wurde bei Earth, Mega-Event und Wherigo einfach der GC-Wert übernommen. Das ist ein Fehler. Man hätte beim internen Mapping einfach hochzählen sollen und beim Import die entsprechenden Änderungen vornehmen sollen.

2. An allen stellen im Code sollten diese Konstanten verwendet werden anstatt die Zahlen direkt zu schreiben.

3. Wozu dieses Subtraction um 128? Warum benutzen wir nicht direkt einen vorzeichenlosen Datentyp (char?)?

Bei Umsetzung dieser Punkte wären intern auch (ausgenommen Im/Export) keine Konvertierungen mehr nötig und es könnte immer mit dem gleichen Datentyp gearbeitet werden.

Wie sind die Meinungen dazu? Wer setzt es um?

 

[Geo-Johnny]

Ich hoffe, dass diese letzten Fragen innerhalb einer Woche geklärt sind. Danach kann man wohl sicher updaten (aber nicht mehr downgraden). Ich werde mich um eine entsprechende "Entwarnung" kümmern, wenn ich der Meinung bin, dass wir soweit sind.

Lieben Dank MiK, nur keinen Stress! Macht es wie immer, Nägel mit Köpfen. Gutding braucht Weile.
Grüße und viel Erfolg der ganzen Crew ...
Johnny

 

[Engywuck]

Dabei wurde bei Earth, Mega-Event und Wherigo einfach der GC-Wert übernommen. Das ist ein Fehler.

Das klingt freundlicher, als es ist: Es gibt zwar verschieden benannte Konstanten für GC und OC, der Wert ist aber der gleiche. Ich glaube aber auch nicht, das das stört. Wenn ich wissen will, ob ein Tradi ein GC- oder ein OC-Tradi ist, dann kann ich den Wegpunkt analysieren. In der Regel interessiert es mich aber nur, ob es ein Tradi ist oder was anderes - eine Unterscheidung zwischen OC- oder GC-Tradi brauchts da nicht. Oder übersehe ich da was?

2. An allen stellen im Code sollten diese Konstanten verwendet werden anstatt die Zahlen direkt zu schreiben.

Klingt unproblematisch und vernünftig.

3. Wozu dieses Subtraction um 128? Warum benutzen wir nicht direkt einen vorzeichenlosen Datentyp (char?)?

Weil man dann einen Wertebereich von 256 hat, und nicht nur 128. Kann man Chars auch als vorzeichenlose Bytes betrachten? Dann wäre das natürlich eine Alternative gewesen. Allerdings halte ich die Subtraktion auch nicht für problematisch und nicht für einen Grund, die Datenstruktur diesbezüglich noch zu ändern. Schließlich würde das die bereits umgestellten Profile zerhauen.

Bei Umsetzung dieser Punkte wären intern auch (ausgenommen Im/Export) keine Konvertierungen mehr nötig und es könnte immer mit dem gleichen Datentyp gearbeitet werden.

Die interne Umstellung, dass CacheTypen jetzt alle als byte (oder char) dargestellt werden, hab ich erstmal gelassen, um die Baustelle nicht zu groß werden zu lassen. Das kann man ja noch nachziehen, wenn man will, allerdings halte ich das nicht für äußerst dringlich.

Gruß,
E.

 

[Engywuck]

Micro GC1KGFM
Small GC1HZYR
Regular GC10CXG
Large GCZBT0
Not chosen GC16YKK
Other GC1Q88V
Virtual GCK02P

Ausprobiert mit "Other" und "Not chosen" - klappt. An dieser Stelle sehe ich keine Probleme.

Gruß,
E.

 

[greiol]

3. Wozu dieses Subtraction um 128? Warum benutzen wir nicht direkt einen vorzeichenlosen Datentyp (char?)?

Weil man dann einen Wertebereich von 256 hat, und nicht nur 128. Kann man Chars auch als vorzeichenlose Bytes betrachten? Dann wäre das natürlich eine Alternative gewesen. Allerdings halte ich die Subtraktion auch nicht für problematisch und nicht für einen Grund, die Datenstruktur diesbezüglich noch zu ändern. Schließlich würde das die bereits umgestellten Profile zerhauen.

das problem ist nicht der 128er trick, sondern die tatsache, dass er direkt mit zwei ausnahmen versehen wurde. datenverlust kann bei nutzung eines NB eintreten. deshalb würde ich es mittelfristig auch begrüssen wenn wir wieder stärker vermitteln könnten was stabil ist und was nicht. sonst nehmen wir uns die möglichkeit in der entwicklung sachen auszuprobieren und das wäre mindestens genauso fatal.

 

[greiol]

3. Wozu dieses Subtraction um 128? Warum benutzen wir nicht direkt einen vorzeichenlosen Datentyp (char?)?

char kann (zumindest seit 1.4.2) unicode aufnehmen, dürfte also zumindest von den "klassischen" jvms als 16bit oder größer implementiert sein. es hindert uns aber niemand daran einfach festzulegen, dass ein tradi die -99 hat. es wird ohnehin nur an einer stelle umgerechnet und an allen anderen sollte die konstante auftauchen also stört das niemanden.

 

[greiol]

Frage eines NB-Fans:
Wird es auch eine entsprechende "Entwarnung" geben, oder zumindest eine kurze Erklärung was man unbedingt vermeiden sollte?

alle daten die mir wichtig sind habe ich noch in einer cw version vor 1787. um die aktuellen versionen zu testen kopiere ich mir das verzeichnis und arbeite mit der kopie. änderungen mache ich auf dem altbestand und kopiere ggf. erneut zum testen.

 

[MiK]

Dabei wurde bei Earth, Mega-Event und Wherigo einfach der GC-Wert übernommen. Das ist ein Fehler.

Das klingt freundlicher, als es ist: Es gibt zwar verschieden benannte Konstanten für GC und OC, der Wert ist aber der gleiche. Ich glaube aber auch nicht, das das stört. Wenn ich wissen will, ob ein Tradi ein GC- oder ein OC-Tradi ist, dann kann ich den Wegpunkt analysieren. In der Regel interessiert es mich aber nur, ob es ein Tradi ist oder was anderes - eine Unterscheidung zwischen OC- oder GC-Tradi brauchts da nicht. Oder übersehe ich da was?

Ich verstehe das eher so: Man benutzt die GC/OC-Konstanten beim Import um den Typ zu erkennen und speichert dann intern immer mit der Kodierung nach CW-Konstanten.

3. Wozu dieses Subtraction um 128? Warum benutzen wir nicht direkt einen vorzeichenlosen Datentyp (char?)?

Weil man dann einen Wertebereich von 256 hat, und nicht nur 128. Kann man Chars auch als vorzeichenlose Bytes betrachten? Dann wäre das natürlich eine Alternative gewesen. Allerdings halte ich die Subtraktion auch nicht für problematisch und nicht für einen Grund, die Datenstruktur diesbezüglich noch zu ändern. Schließlich würde das die bereits umgestellten Profile zerhauen.

char ist 8 Bit unsigned und byte ist 8 Bit signed. Diese Verschiebung anstatt der Verwendung von char macht den Code wohl etwas weniger verständlich. Ich hatte es auch erst nicht verstanden (dachte die Werte wären alle zu größer 128 und müssten deswegen verschoben werden) und sie ist wohl auch zum Teil für die "Verwirrung" von Greiol verantwortlich.

Bei neuen Cachetypen müssen wir nun immer schauen, ob der berechnete Wert noch frei ist und evtl. sonderbehandeln. Wenn wir aber immer alle externen Werte auf eine fortlaufende CW-Kodierung mappen würden, wäre hier eine potentielle Fehlerquelle vermieden.

Falls wir uns für diese Umstellung auf einen fortlaufenden (Addis wohl weiter in einem getrennten Bereich) CW-Code entscheiden, könnten wir auch gleichzeitig noch die 128-Verschiebung beseitigen.

Ich fände es besser jetzt noch mal in den sauren Apfel zu beißen und das gerade zu ziehen als "ewig" diese Altlasten mit uns rumzuschleppen.

 

[MiK]

3. Wozu dieses Subtraction um 128? Warum benutzen wir nicht direkt einen vorzeichenlosen Datentyp (char?)?

char kann (zumindest seit 1.4.2) unicode aufnehmen, dürfte also zumindest von den "klassischen" jvms als 16bit oder größer implementiert sein. es hindert uns aber niemand daran einfach festzulegen, dass ein tradi die -99 hat. es wird ohnehin nur an einer stelle umgerechnet und an allen anderen sollte die konstante auftauchen also stört das niemanden.

Gibt es denn keinen Datentyp für vorzeichenlose 8 Bit mehr?
Aber ok, wenn wir dann eben direkt in der CW-Kodierung negative Konstanten benutzen, dann ist byte genauso gut. Ich finde es nur blöd intern immer diese Verschiebung einrechnen zu müssen.

Also mein Vorschlag: Wir bleiben bei Byte, belegen aber das CW-Mapping neu. Und zwar so, dass sie bei den meisten Cachetypen der jetzigen toByte-Methode entspricht. Nur bei Earth, Mega und Wherigo vergeben wir neue fortlaufende Werte. So sparen wir uns Umrechnung und Sonderbahandlungen.

Außerdem ist es für bereits konvertierte Daten kein kompletter Datenverlust, sondern nur einige wenige Caches verlieren ihren Typ, was leicht durch Aktualisieren dieser Caches behoben werden kann.

 

[Engywuck]

Gibt es denn keinen Datentyp für vorzeichenlose 8 Bit mehr?

Hatte ich beim Lesen in der Java-Dokumentation auch nicht gefunden...

Also mein Vorschlag: Wir bleiben bei Byte, belegen aber das CW-Mapping neu. Und zwar so, dass sie bei den meisten Cachetypen der jetzigen toByte-Methode entspricht. Nur bei Earth, Mega und Wherigo vergeben wir neue fortlaufende Werte. So sparen wir uns Umrechnung und Sonderbahandlungen.

Hm. Wenn Du die Umrechnung sparen willst, wäre ich dafür, den internen Wert als int (oder char) abzulegen, und beim speichern/laden die byte-Umrechnung wie bislang zu machen.

Außerdem ist es für bereits konvertierte Daten kein kompletter Datenverlust, sondern nur einige wenige Caches verlieren ihren Typ, was leicht durch Aktualisieren dieser Caches behoben werden kann.

Der interne Wert muss ja nicht fortlaufend sein. Das wäre nur eine Frage der Ästhetik. Man kann ja durchaus die Werte nehmen, die bislang auch genommen werden, dann hätte man keine Probleme.

Gruß,
E.

 

[greiol]

Außerdem ist es für bereits konvertierte Daten kein kompletter Datenverlust, sondern nur einige wenige Caches verlieren ihren Typ, was leicht durch Aktualisieren dieser Caches behoben werden kann.

Der interne Wert muss ja nicht fortlaufend sein. Das wäre nur eine Frage der Ästhetik. Man kann ja durchaus die Werte nehmen, die bislang auch genommen werden, dann hätte man keine Probleme.

ich wäre für einen klaren sauberen schnitt. selbst wenn wir nur den positiven tyeil des byte nehmen haben wir erst mal 0 bis 127 was mehr als ausreichen dürfte um sogar die bisher nicht unterstützten eher seltenen typen aufzunehmen. mit dem negativen teil dazu können wir vermutlich noch drei andere cachplatformen unterstützen und haben dann immer noch luft nach oben. und sollte gar nichts mehr gehen, flicken wir den leuten halt einmalig ihren code zusammen, auch wenn ich der meinung bin, dass der NB nicht die daily stable ist.

ein datenverlust kann einsatz der NB version vorkommen. das sollte einfach jedem klar sein, der sie benutzt.

 

[MiK]

Also mein Vorschlag: Wir bleiben bei Byte, belegen aber das CW-Mapping neu. Und zwar so, dass sie bei den meisten Cachetypen der jetzigen toByte-Methode entspricht. Nur bei Earth, Mega und Wherigo vergeben wir neue fortlaufende Werte. So sparen wir uns Umrechnung und Sonderbahandlungen.

Hm. Wenn Du die Umrechnung sparen willst, wäre ich dafür, den internen Wert als int (oder char) abzulegen, und beim speichern/laden die byte-Umrechnung wie bislang zu machen.

Genau diese Umrechnung hätte ich aber gerne komplett raus. Warum sollen wir während den Programmlaufs mit anderen Werten arbeiten als wir speichern?

Außerdem ist es für bereits konvertierte Daten kein kompletter Datenverlust, sondern nur einige wenige Caches verlieren ihren Typ, was leicht durch Aktualisieren dieser Caches behoben werden kann.

Der interne Wert muss ja nicht fortlaufend sein. Das wäre nur eine Frage der Ästhetik. Man kann ja durchaus die Werte nehmen, die bislang auch genommen werden, dann hätte man keine Probleme.

Wenn wir sowieso ummappen müssen, damit es in ein Byte passt, dann natürlich aus ästhetischen Gründen fortlaufend.

Ich verstehe, dass Du das Format nicht noch einmal ändern möchtest, aber ich denke es ist besser jetzt in den sauren Apfel zu beißen und es sauber zu machen. Jetzt haben wir noch die Gelegenheit, ohne dass es viele betrifft. Später ist es ein weiteres altes Format, dass wir unterstützen müssen. Wenn man das jetzt so umbaut, dass die drei (seltenen) Cachetypen, die eine "falsche" Nummer haben, trotzdem mit "unbekanntem Typ" angezeigt werden, dann ist es für die "early adopters" auch kein großer Aufwand ihren Datenbestand gerade zu ziehen.

 

[MiK]

ein datenverlust kann einsatz der NB version vorkommen. das sollte einfach jedem klar sein, der sie benutzt.

Wenn man es geschickt macht, ist es ja auch kein Datenverlust. Nur die Cachetypen werden nicht mehr richtig erkannt. Je nachdem, ob wir die Verschiebung ins negative Beibehalten sind das nur wenige oder eben alle.

Aber ich bin auch dafür jetzt nochmal den harten Schnitt zu machen.

 

[Engywuck]

Genau diese Umrechnung hätte ich aber gerne komplett raus. Warum sollen wir während den Programmlaufs mit anderen Werten arbeiten als wir speichern?

Weil ich es jetzt erstmal so implementiert hab. Als ich den Code als Patch gepostet hab, hat sich auch keiner die Mühe gemacht, sich das Zeug runterzuladen und anzugucken. Da finde ich es ehrlich gesagt etwas seltsam, wenn jetzt die Welle gemacht wird, weil man in der Datei lieber ne 0 als ne -128 abspeichert.

Ich verstehe, dass Du das Format nicht noch einmal ändern möchtest, aber ich denke es ist besser jetzt in den sauren Apfel zu beißen und es sauber zu machen.

Wenn es denn überhaupt dreckig wäre... Aber so wie ich das sehe, geht es darum, ob in der Datei negative Zahlen stehen oder nicht und ob die interne Zahlenrepräsentation fortlaufend ist oder nicht. Alles Dinge, die mit Funktionalität nicht die Bohne zu tun haben.
Manchmal kann ich echt nur den Kopf schütteln..

Gruß,
E.

 

[greiol]

Als ich den Code als Patch gepostet hab, hat sich auch keiner die Mühe gemacht, sich das Zeug runterzuladen und anzugucken.

der einwand ist berechtigt.

Da finde ich es ehrlich gesagt etwas seltsam, wenn jetzt die Welle gemacht wird, weil man in der Datei lieber ne 0 als ne -128 abspeichert.

nochmal: es geht nicht darum ob ein tradi -1, 0 oder 1 ist. das problem ist, dass die derzeitige implementierung eine regel mit zwei ausnahmen ist, statt einfach nur eine regel zu sein. die lösung hat einen hohen hack value, bietet aber auch potetntial für zukünftige probleme.

aus diesem grund würde ich eine regel die ohne ausnahmen auskommt bevorzugen, denn sie ist einfacher zu merken.

Aber so wie ich das sehe, geht es darum, ob in der Datei negative Zahlen stehen oder nicht und ob die interne Zahlenrepräsentation fortlaufend ist oder nicht.

genau darum geht es nicht. von mir aus, kannst du die dinger auch nach belieben . , A J K oder \u0045 nennen und in einem char statt einem byte speichern, solange klar erkennbar ist, dass es eine blöde idee ist für den nächsten wegpunkt den identifier A zu vergeben weil er eben schon benutzt wird.

wenn du immer 128 abziehen oder addieren würdest wäre gegen die lösung auch nichts einzuwenden. die lösung mit "immer, außer" ist es die mir bauchschmerzen macht.

Alles Dinge, die mit Funktionalität nicht die Bohne zu tun haben.

zu einem "es funktioniert heute", sollte im idealfall auch ein "es funktioniert morgen" und es "funktioniert wenn ein anderer dran arbeiten muss" dazu gehören.

Manchmal kann ich echt nur den Kopf schütteln..

es bestreitet niemand, dass das was du da geschrieben hast funktional ist. und die idee ist gut. wenn wir es jetzt noch schaffen sie idiotensicher zu machen (falls leute wie ich vorbei kommen), ist sie perfekt.

 

[Engywuck]

nochmal: es geht nicht darum ob ein tradi -1, 0 oder 1 ist. das problem ist, dass die derzeitige implementierung eine regel mit zwei ausnahmen ist, statt einfach nur eine regel zu sein.

D.h. Du willst es ersetzen durch eine Variante ohne Regel und nur mit ausnahmen? Wenn ich sowas mache wie

switch (type) {
	case EX_TRADI: result=CW_TRADI; break;
	case EX_MULTI: result=CW_MULTI; break;
    ...
end;

und so weiter für alle 25 Cachetypen, käme ich mir etwas blöd vor, wenn der externe und der interne Wert für 23 von 25 Typen identisch ist. Mein spontaner Gedanke, wenn ich das lese, wäre "Hätte man das nicht über eine Funktion mit 2 Ausnahmen kürzer und prägnanter formulieren können" ? Aber gut, die Geschmäcker sind verschieden...

Gruß,
E.