Wieder mal ein XppFatal

[Tom]

Hallo, Hubert.

Selbstverständlich sollte die Errorsys sehr robust sein, also sich nicht darauf verlassen, dass Systematiken funktionieren, die selbst Fehlerursache sein können.

Ich sehe, mal von den Möglichkeiten abgesehen, auch keine Perspektive für kaufmännische Software, die Laufzeitfehler simpel loggt und dann einmal am Tag irgendein Protokoll erzeugt (was, unter uns gesagt, einmal zu oft ist). Das Fehlersystem erlaubt es, mit Situationen zu hantieren und diese auch zu umgehen, etwa jene, wenn Virenscanner kaskadieren und beim Öffnen vieler Dateien nacheinander Timeouts generieren. Es gestattet es, auf erwartete, aber nicht vorhandene Tabellenfelder oder Tabellen selbst zu reagieren, und auf vieles mehr. Ich habe unser Fehlersystem so weit ausgebaut, dass bei uns letztlich fast nur noch echte Fehler ankommen. Alles andere versucht die Errorsys, eigenständig zu korrigieren oder wenigstens Hinweise auf Behebungsmöglichkeiten zu geben. Und - was soll ich sagen? Es funktioniert.

[brandelh]

die Laufzeitfehler simpel loggt und dann einmal am Tag irgendein Protokoll erzeugt

ich schrieb, dass das Programm beim Start nachsieht ob eine XppError.LOG bzw. XppFatal.LOG vorhanden ist und diese dann versendet
Das kam am Anfang alle paar Monate mal vor, bis alle Tippfehler beseitigt waren. Jetzt so gut wie gar nicht mehr.

Fehlende DATEN-Dateien moniert mein Programm beim Start, fehlende Indexe werden vor dem Zugriff automatisch erzeugt.
Meine CGI Anwendungen prüfen beim Datenimport ob die Struktur geändert wurde und bereinigt dies (Neue Felder anfügen, Feldlängen erweitern etc.)

Alles altmodisch vorsorglich ohne das Fehlersystem aufzurufen

Ich kann mir gut vorstellen, dass du mit deinen vielen verschiedenen Installationen / Versionen / Kunden hier mehr Aufwand treiben mußt.

[Markus Walter]

Das Fehlersystem erlaubt es, mit Situationen zu hantieren und diese auch zu umgehen, etwa jene, wenn Virenscanner kaskadieren und beim Öffnen vieler Dateien nacheinander Timeouts generieren. Es gestattet es, auf erwartete, aber nicht vorhandene Tabellenfelder oder Tabellen selbst zu reagieren, und auf vieles mehr. Ich habe unser Fehlersystem so weit ausgebaut, dass bei uns letztlich fast nur noch echte Fehler ankommen. Alles andere versucht die Errorsys, eigenständig zu korrigieren oder wenigstens Hinweise auf Behebungsmöglichkeiten zu geben. Und - was soll ich sagen? Es funktioniert.

Na das wäre doch mal eine Session wert...

[Wolfgang Ciriack]

Ja, das wäre interessant !

[AUGE_OHR]

WOW ... dann "vertraust" du dem OS() aber ein Menge zu !

Ich traue dem OS genau das zu, was es auch können sollte. Und ich fahre exzellent damit.
...
Fatals sind ein anderes Problem. Die etwas haarige Idee, nach einem Fatal einfach den Rechner zu booten, erinnert mich jedoch an Zeiten, wo man noch froh war, dass die Kiste überhaupt gestartet ist. Jemanden, der mir eine solche Software verkaufen würde, würde ich sofort nach der Auslieferung verklagen.

du redest von "normalen" Fehler die im Fehler System "ankommen", das ist "trivial"

wenn ich aber mit der Win API "rum-spiele" und eine Pointer falsch setzte bekomme ich eine "buffer overflow" aber der Speicher wird nicht "bereinigt".
ein gutes Beispiel ist die System Image List oder Ownerdraw ... da möchte ich mal sehen wie du damit noch "weiterarbeiten" willst ...

wie ich schon sagte entstehen XppFatal.log wenn Xbase++ den Fehler nicht per

Code: Alles auswählen

XBPException():RaiseParameterXXX(xValue)

abgefangen wird ... und dann kann man nichts mehr machen.

[UliTs]

Tom,

wie schaffst Du es denn, die XppFatal.Log zu verändern?
Ich habe es nur durch den Trick geschafft, dass ich das Standardverzeichnis entsprechend einstelle, um zumindest den Pfad auf ein Verzeichnis mit Schreibberechtigung für die XppFatal.Log umbiegen zu können.

Uli

[Tom]

wenn ich aber mit der Win API "rum-spiele"

Ich "spiele nicht rum", vor allem nicht im Kontext von Software, die im realen Leben eingesetzt wird. Ich käme niemals auf die Idee, das Ergebnis einer "Herumspielerei" an Kunden auszuliefern. Insofern ist dieses Szenario aus meiner Sicht irrelevant.

[AUGE_OHR]

wenn ich aber mit der Win API "rum-spiele"

Ich "spiele nicht rum", vor allem nicht im Kontext von Software, die im realen Leben eingesetzt wird. Ich käme niemals auf die Idee, das Ergebnis einer "Herumspielerei" an Kunden auszuliefern. Insofern ist dieses Szenario aus meiner Sicht irrelevant.

jaja ist schon gut ... ich spreche von der Entwicklungsphase wo man "die Limits auslotet" das man mal ein Xppfatal bekommt.

wenn es dann wirklich beim Kunden zu einem Xppfatal durch "meine" Xbase++ Application kommen sollte der NICHT vorher durch meine Errorsys angefangen wurde "dann" rate ich dazu es nochmals zu versuchen, nach einem "re-boot" !!!
sollte dann das selbe in "meiner" Xbase++ Application wieder passieren "dann" habe "ich" ein Problem.




aber kommen wir doch lieber auf das Problem von Jan zurück.

auch wenn der Hotfix Nr. 36 die Grenze anhebt haben wir mit Xbase++ ein grosses Problem weil wir ja nicht den Speicher für ein "riesiges" Array "anfordern" können.

Code: Alles auswählen

das geht nicht

LOCAL aArray := ARRAY[1000000]

das geht

LOCAL aArray := {}

  FOR i := 1 To 1000000
        AADD(aArray,"")
  NEXT

nun kommt aber das Problem das es sich nicht um "zusammenhängende" Speicherbereiche handelt ... es muss dann "umgeschaufelt" werden. nun reicht also ein einzelner Block, der nicht mehr "passt" aus wenn du am Limit bist und es "knallt"

aber Hubert schon sagte vielleicht benötigt man hier einen "anderen" Ansatz.

auf der Devcon erzählte mir "Frans Vermeulen" etwas von einem "riesigen" Report wo er mit 2 Million Daten arbeiten wollte ...
aber nicht mit einem Array sondern einem Bitmap (!!!)
jeder Pixel stellt ein Element dar und die Farbe (16 Mil.) den "Wert" und die "Berechnungen" erfolgen wohl per RGB Werte was Simon Burford ihm geliefert hat.

[UliTs]

... auf der Devcon erzählte mir "Frans Vermeulen" etwas von einem "riesigen" Report wo er mit 2 Million Daten arbeiten wollte ...
aber nicht mit einem Array sondern einem Bitmap (!!!)
jeder Pixel stellt ein Element dar und die Farbe (16 Mil.) den "Wert" und die "Berechnungen" erfolgen wohl per RGB Werte was Simon Burford ihm geliefert hat.

Coole Idee! Und was sagt die Performance dazu
Ich kann mir nicht vorstellen, dass man da mit xBase auf akzeptable Geschwindigkeiten kommt.

Uli

[AUGE_OHR]

Coole Idee! Und was sagt die Performance dazu
Ich kann mir nicht vorstellen, dass man da mit xBase auf akzeptable Geschwindigkeiten kommt.

bei 1920 x 1080 x 16M = 8 GB.
da er wohl mit den GDI(+) API arbeitet kann man damit ggf die GPU der GFK nutzen mit DDR-5 VRAM

soviel ich das verstanden habe, kann man mit der Xoanon Lib, schon diese Bitmap "Manipulationen" per GDI32 durchführen.
unter Win7 haben wir nun die 3-D Effecte was dann die GDI(+) API enthalten soll ... und die API zur Nutzung der GPU

was die Performance angeht bin ich mich nicht sicher ob die auch in dem "Zoom" Modul von Pablo drin steckt aber das hatte "Gamer" Qualität
aus der Satelliten Ansicht bis zum "Blumentopf" zu "zoomen" ging praktisch "stufenlos" ... hin und zurück.

sicherlich ist die Idee sehr speziell aber für "riesige" Array die mehr als 2 Millionen Handle benötigen sollte man unbedingt eine "pure" Xbase++ Lösung einsetzten

[brandelh]

sicherlich ist die Idee sehr speziell aber für "riesige" Array die mehr als 2 Millionen Handle benötigen sollte man unbedingt eine "pure" Xbase++ Lösung einsetzten

Ich meinte eher, dass man die Daten anders vorhält.
Vor einiger Zeit hatte ich mal getestet was schneller geht, eine Datei in Arrays einlesen oder direkt (mit Index) zu verarbeiten.
Ich meine, dass ab 200 MB die interne Speicherverwaltung langsamer wird als die Indexzugriffe.

ASeek() sucht sequentiell !

Ein Ansatz wäre z.B. eine Klasse oder Struktur, deren Elemente in einem eindimensionalen Array gespeichert werden.

Angenommen 100 Elemente in der zweiten Dimension mit Text und 1000 Zeilen ... würde normalerweise 100*1000 Speicherhandles verbraten.
Sonst nur 1000 mit je einem Objekt.

Ginge es nur um die Geschwindigkeit könnte man die "Hash Table Functions" von Pablo nutzen.

Wie gesagt, man sollte den Ansatz komplett überdenken.