Änderung im Dateiformat

[greiol]

[*] Für die interne Repräsentation der Sizes solltest Du die Werte nehmen, die ich schon in CacheHolder (ab Zeile 50) verwendet habe.

ok, das ist sinnvoll.

[*] Würde die Klasse static final machen

auch kein problem

[*] Ich halte nicht so viel davon, jetzt schon jede Menge Code einzubauen für Zwecke, die bislang noch gar nicht benötigt werden. Wenn bislang keine Images exportiert werden, braucht man dafür auch keine Methode anzulegen oder Konstanten zu definieren - das macht nur die Exe unnötig größer. Wenn man die Methode braucht, kann man sie erstellen, das ist ja dann unproblematisch.

korrekt, ich hatte die heute mehr oder weniger offline geschrieben und als ich fertig war, fiel mir ein, dass ich mir den source nochmal anschauen muss ob wir das überhaupt brauchen. aber da löschen im zweifel schneller geht als nochmal tippen, habe ich sie erst mal drin gelassen

[*] Bei den Exceptions sollte noch eine Message dazu, die angibt, welcher Typ denn gerade nicht unterstützt wurde.

daran soll es nicht scheitern.

nach dem schema würde ich gerne auch CacheType umbauen. CacheDiffTerr könnte auch ein kandiadat sein.

 

[Engywuck]

natürlich käme, falls das so implementiert würde noch die (zugegeben lästige) fleissarbeit herauszufinden wo das im moment noch überall hart verdrahtet

Och, wenn Du einfach mal den Datentyp der CacheSize von String auf Byte setzt, ohne sonst was zu machen, wird Eclipse Dir schon erzählen, wo ihm schlecht wird ;-)

Gruß,
E.

 

[greiol]

natürlich käme, falls das so implementiert würde noch die (zugegeben lästige) fleissarbeit herauszufinden wo das im moment noch überall hart verdrahtet

Och, wenn Du einfach mal den Datentyp der CacheSize von String auf Byte setzt, ohne sonst was zu machen, wird Eclipse Dir schon erzählen, wo ihm schlecht wird ;-)

ich bin mir gar nicht so sicher, ob ich das alles sehen will :schockiert:

 

[greiol]

ich bin mir gar nicht so sicher, ob ich das alles sehen will :schockiert:

das geht besser als erwartet. die mappings für terracaching musste ich noch nachtragen und die ganzen methoden static machen. im moment bereitet mir noch der filter etwas kopfschmerzen. da muss ich mir mal ansehen was der treibt, denn da werden die größen ja wieder von einem byte zu einer bitmaske :-\ da muss ich wohl wie bei der anzeige im panel ein paar zusammen fassen.

Edit: 240 zeilen änderungen damit es kompiliert. morgen schauen wir mal ob es auch funktioniert

 

[Engywuck]

Edit: 240 zeilen änderungen damit es kompiliert.

Hey, it compiles - ship it! ;-)

 

[greiol]

könnte ich, aber da die gui in weiten teilen bisher ohne try / catch blöcke lebt, ist das derzeit eher etwas für liebhaber bildschirmfüllender stack traces

 

[Hellenstones]

Als spontaner Effekt sollte sich eine Verbesserung der Ladegeschwindigkeit (1/3 bis 1/5 weniger Ladezeit) zu bemerken sein.

Ist das wirklich wahr :schockiert: :schockiert: :schockiert: !?!??!?!??!?!?!?!
Das wäre ja traumhaft!!!
Für meinen schon etwas altersschwachen Medion wäre das ja genial!!

Wie sind denn hier die Entwicklungsarbeiten? Kann man schon einen Nightly Build verwenden oder ist das neue Format noch instabil???
Benutze derzeit CW 1781.

Danke an alle die hier zu CW beitragen , ich bin ja zu blöd für sowas !!!

 

[apfelmaus]

Als spontaner Effekt sollte sich eine Verbesserung der Ladegeschwindigkeit (1/3 bis 1/5 weniger Ladezeit) zu bemerken sein.

Diese Auswirkung konnte ich auf der mobilen Cachewolf version leider nicht nachvollziehen. Ein Profil mit 100 Caches brauchte mit dem alten Dateiformat 9,7 Sekunden zum Laden, mit dem Neuen 11,5 Sekunden.
Wahrscheinlich treten auf einem PDA zusätzliche Effekte eine Rolle (limitierte CPU, Lesegeschwindigkeit von der SD Karte, ...)

Mein Equipment ist ein HTC Touch Cruise mit 8GB SDHC Sandisk Karte für die CacheWolf Daten. Zuerst habe ich Cachewolf mit einem leeren Profil geladen und dann im Hauptmenu das Profil gewechselt und die Zeit bis zum Anzeigen der Caches gemessen.

 

[Engywuck]

Als spontaner Effekt sollte sich eine Verbesserung der Ladegeschwindigkeit (1/3 bis 1/5 weniger Ladezeit) zu bemerken sein.

Diese Auswirkung konnte ich auf der mobilen Cachewolf version leider nicht nachvollziehen. Ein Profil mit 100 Caches brauchte mit dem alten Dateiformat 9,7 Sekunden zum Laden, mit dem Neuen 11,5 Sekunden.

Bei mir waren die Ergebnisse auch unterschiedlich. Ich weiss es nicht so richtig zu interpretieren. Bei einem Profil habe ich die Ladezeit mal von 90sec auf 65 sec gedrückt, bei einem anderen blieb es im wesentlichen bei 40 sec.

Gruß,
E.

 

[Geo-Johnny]

Baahhh, jetzt lasst die Jungs mal machen, ist ja noch nicht fertig die ganze Umstellerei. MiK hat versprochen, daß er Bescheid gibt, wenn alles wieder im Lot ist.

 

[greiol]

Wie sind denn hier die Entwicklungsarbeiten?

du hast die postings im fred gelesen?

Kann man schon einen Nightly Build verwenden

man kann immer einen nightly build verwenden, wenn man den unterschied zwischen einem nightly build und einer stabilen version versteht

oder ist das neue Format noch instabil???

die nächste zeile bitte an prominenter stelle auf dem monitor fixieren:
EIN NIGHTLY BUILD IST PER DEFINITION KEINE STABILE VERSION

 

[Hellenstones]

:/ Das ist mir auch klar!!!!! :/
Aber aufgrund der Tatsache das es seit langem keine offizielle stabile Version mehr gegeben hat und alle von mir bisher verwendeten Nightly Builds ohne Problemem funktioniert haben kann man so ein Frage doch mal stellen, oder!?!?

Es ging mir nur darum zu erfahren inwieweit das neue Dateisystem schon integriert ist, damit ich nicht mit jeder Änderung mir mein Profil komplett neu aufbauen muss.
Und ja, ich habe den Fred gelesen, allerdings ist für nicht Fachmänner nicht so einfach nachzuvollziehen wie der aktuelle Stand gerade ist...

 

[Engywuck]

nach dem schema würde ich gerne auch CacheType umbauen. CacheDiffTerr könnte auch ein kandiadat sein.

Klingt gut. Mach doch mal

Gruß,
E.

 

[greiol]

Und ja, ich habe den Fred gelesen, allerdings ist für nicht Fachmänner nicht so einfach nachzuvollziehen wie der aktuelle Stand gerade ist...

hast du in diesem fred bisher irgend etwa sgelesen, was darauf hindeuten würde, dass die änderungen vollständig fertig sein könnten? steht hier nicht vielmehr in jedem 5. artikel etwas von fehlermeldungen, vorsicht, backup machen?

sobald wir der festen überzeugung sind, dass wir mit dem format fertig sind, werden wir das verkünden und auch die info von den Hawks auf dem NB server wird sich ändern.

 

[Engywuck]

Ich habe einmal die Klasse Legacy.java hinzugefügt. Diese hat bislang ein paar sehr allgemeine Methoden, um Daten aus alten Versionen in die entsprechenden Inhalte neuer Versionen zu überführen.
Als eigene Klasse hauptsächlich deshalb, um den Code, den der "aktive" CacheWolf benötigt nicht mit den Methoden zu verunreinigen, die nur notwendig sind, um ältere Dateiversionen noch einlesen zu können.
Aktuell bin ich mal davon ausgegangen, dass das neu zu definierende Format Version 3 wird. Unterschiede zwischen Version 2 zu 3 gibt es dann vermutlich nur bezüglich des CacheType (ok, sicher kann man nie sein...). Strukturell wird sich ja hoffentlich nichts mehr tun (so dass der Code in CacheHolder(String, int) unverändert bleiben kann).

Gruß,
E.

 

[greiol]

ich habe eben den it-works-for.me(TM) patch für die cachegröße reingeschossen. da ich bis in den filter geändert habe, musste ich bei 1er profilen einmal alle größen auschalten, anwenden und wieder einschalten damit alle cache sichtbar wurden. bei 2er profilen gibt es ein problem mit der darstellung von non physical caches. ist mit einer aktualisierung der caches behoben.

könnte bitte jemand über die basiskonstanten schauen? dann könnten wir die werte zumindest fest machen und würden auch an der stelle staibl.

auf zur nächsten baustelle.

 

[Engywuck]

Die Konstanten sollten ok sein.
Spricht etwas dagegen,

• die Methode CacheSize.v1Converter in Klasse Legacy auszulagern?
• die neue Version Version 3 zu nennen? Dann bleiben wir vollständig abwärtskompatibel (auch mit den zwischenzeitlich vorhandenen NBs) mit einem Minimum an zusätzlichem Code.

Gruß,
E.

 

[greiol]

Die Konstanten sollten ok sein.

fein

[*] die Methode CacheSize.v1Converter in Klasse Legacy auszulagern?

ist halt hin und her gehüpfe. ich habe sie jetzt einfach mal als deprecated geflaggt, damit man sie später findet. ich steh dem neutral gegenüber und warte mal andere stimmen ab

[*] die neue Version Version 3 zu nennen? Dann bleiben wir vollständig abwärtskompatibel (auch mit den zwischenzeitlich vorhandenen NBs) mit einem Minimum an zusätzlichem Code.

vollständig wird das ohnehin nicht, da wir von den alten größen auf die erste variante der v2 größen schon information verloren haben. die lässt sich leider auch nicht mehr herstellen und wer die eingesetzt hat, wir in einigen teilen nicht umhin kommen seine caches zu aktualisieren.. ich könnte aber damit leben, dass wir während der umstellung komplett bei v2 bleiben und wenn wir alle byte felder so haben wie wir das wollen auf v3 schwenken. einen geraden migrationspfad ohne nachträgliches aktualisieren werden wir aber aus den oben genanten gründen vielleicht 1 -> 3 schaffen, nicht aber 2 -> 2a (ich gehe derzeit von mindetens einem b und evtl einem c aus) -> 3.

 

[MiK]

• die neue Version Version 3 zu nennen? Dann bleiben wir vollständig abwärtskompatibel (auch mit den zwischenzeitlich vorhandenen NBs) mit einem Minimum an zusätzlichem Code.

Ich würde eher bei 2 bleiben, die Zwischenversionen "fehlerbehaftet" nennen und diesen Umwandlungscode (2->3) sparen. Es passiert ja nichts, was man nicht mit dem Aktualisieren von ein paar Caches beheben könnte.

Aber wenn Du darauf bestehst, kann ich auch mit "Version 3" leben.

 

[Engywuck]

die Zwischenversionen "fehlerbehaftet" nennen

Fehlerbehaftet war da nix. Euch hat nur der Stil nicht gefallen.

und diesen Umwandlungscode (2->3) sparen.

Der Umwandlungscode 2->3 umfasst derzeit 5 Zeilen, ausgelagert in die dafür gedachte Legacy-Klasse.

Aber wenn Du darauf bestehst, kann ich auch mit "Version 3" leben.

In Anbetracht meiner ersten Bemerkung in http://www.geoclub.de/viewtopic.php?p=535449#p535449: Ja.

vollständig wird das ohnehin nicht, da wir von den alten größen auf die erste variante der v2 größen schon information verloren haben.

Welche sollen das denn sein? Wenn noch was fehlt, ist das zwar bedauerlich, aber kein Grund, dafür noch weitere Informationen zu schludern.

Gruß,
E