Seite 1 von 1

Verfasst: So 25 Feb, 2007 10:33 pm
von tschosef
hai hai...

eigentlich werden wir hier krass offtopic :) es geht ja um Popelscan...
wenn das grad stehende beams waren ... kacke.
was das betrifft, das dürfte ja sowiso kein stehender Beam im Puplikumsbereich sein, ansonsten is die show eh nicht als Save an zu sehen. Ich progge eigentlich nie Schows, mit Beams in das Puplikum. Davon halte ich nix.

Ja, das mit dem Fehler abfangen, und dann kontrolliert an einer bestimmten Stelle weiter machen klingt schön. Ist aber nicht immer machbar, denn man kann ja nur fehler auf diese Weise bearbeiten, die man erwarten kann, und deren herkunft man kennt (bestest Beispiel, die [info].txt Datei ist nicht im Ordner. Da merkst du garnix von...

Unvorhersehbare Fehler sind deutlich schwerer ab zu fangen. Eben, wenn ein Index zB außerhalb des zulässigen Bereiches läuft (Array oder so)... was willst dann machen? die routiene abbrechen oder den Index einfach auf irgendeinen wert setzen? Das Ergebniss dürften wohl noch mehr Folgefehler sein.

Nun, ich weis selber auch, dass in HE Laserscan ein paar Sachen nicht ideal geproggt sind. Wundere mich manchmal selber was ich da zusammen gezimmert habe, wenn ich etwas überarbeite. Ich hab in den Jahren in denen das Programm entstand auch dazu gelernt. "Nächstes mal" mach ich alles von Anfang an besser. Mehr Konzept, bevor es überhaupt los geht.


HE-Laserscan hat einen ziemlich chaotischen Anfang. Ziel war es so schnell wie möglich mit LPT DAC eine Ausgabe hin zu bekommen. Mehr nicht.... Genaueres findet man dazu hier, auch wie das Prog damals aussah.
http://www.he-privat.de/Laser/Projektor ... Phase2.htm

viele Grüße
Erich

Verfasst: So 25 Feb, 2007 11:23 pm
von john
icefro hat geschrieben: Wenn in funktionen irgendwas schiefläuft ( z.B. "Linie zeichnen" ) kann man die funktion nochmal versuchen aufzurufen ... oder ganz abbrechen.

Wenn ein teil schiefgeht, muss halt KOMPLETT nochmal von vorne angefangen werden.
Das funktioniert nicht.
Bei einem Computerprogramm sind Fehler unter identischen Startbedingungen garantiert reproduzierbar. Scheitert eine Funktion einmal mit gesetzten Varibablen (z.B. beim Zeichnen der Linie), wird sie es bei gleichem Aufruf wieder tun.

Für nicht sinnvoll angefangene Fehler gibt es aus meiner Sicht nur eine Lösung und die heißt Programm zu. Oder rennst du im echten Leben immer wieder gegen eine zue Tür? NEIN. Du änderst die Startbedingungen (z.B. Tür aufschließen) und wiederholst NACH der Änderung den Aufruf. So clever ist Software aber i.d.R. nicht.

John

Verfasst: So 25 Feb, 2007 11:29 pm
von icelase
das war jetzt auf "aktion zuendeführen" gedacht ... klar bei gleichbleibenden bedingungen -> sinnlos

aber wenn z.B. was fertig geladen werden muss ... oder es zeitlich grad nicht passt weil der buffer schon voll ist.


Aber auch solche abfragen sollte man direkt einprogrammieren .. ( selbstverständlich )


Mir ist vorhin schonwieder HE abgestürzt als ich bei einer laufenden Show eine andere nachladen wollte :) meistens gehts ... manchmal nicht... ist wohl ne timing geschichte.


gruss frank

Verfasst: Mo 26 Feb, 2007 6:08 am
von tschosef
moing moing
als ich bei einer laufenden Show eine andere nachladen wollte Smile
hm, warscheinlich wird auch das Getriebe vom PKW auseinanderfliegen, wenn du bei Laufendem Autobahnbetrieb den ersten Gang rein knallst :)

viele Grüße
Erich

Verfasst: Mo 26 Feb, 2007 9:01 am
von sanaia
icefro hat geschrieben:Bei Errors sollte es halt eine art "return" punkt geben ... also nicht einfach weitermachen, sondern wieder von vorne anfangen .... so GOTO Like. ( aber das muss der coder wieder speziell einproggen )
Du programmierst bestimmt nicht selbst, oder ? Ein programm, was eine 'segmentation violation' erzeugt - und evtl. sich seinen eigenen stack zerschießt - ist nicht mehr überlebensfähig, weil wichtige sachen, wie adresszeiger und evtl. auch rücksprungadressen vernichtet wurden. Sowas kann man nur noch aus dem speicher räumen lassen. In jeder vernünftigen sprache gibt es sowas wie in BASIC 'ON ERROR RESUME ...' nicht, weil das keinen sinn macht.
Ob man nach einer division durch null aussteigen muß, oder die abfängt, darüber kann man sich streiten.
tschosef hat geschrieben:Unvorhersehbare Fehler sind deutlich schwerer ab zu fangen. Eben, wenn ein Index zB außerhalb des zulässigen Bereiches läuft (Array oder so)... was willst dann machen? die routiene abbrechen oder den Index einfach auf irgendeinen wert setzen?
Wo es simm macht, kann man indices durchaus clampen. Ich teste zeiger und indices for verwendung jedesmal auf plausibilität. Bestehen sie den test nicht, macht die funktions nichts. Zumindest im debug mode sollte man aber eine fehlermeldung ausgeben, was los ist - oder im debug modus verzichtet man auf dieses sicherheitsnetz, läßt das prg abstürzen und sucht mit den debugger die ursache, während man im release die tests drin läßt, um abstürze zu vermeiden.

Verfasst: Mo 26 Feb, 2007 9:06 am
von ChrissOnline
Mann lädt ja auch keine Show wenn ne andere noch läuft... :roll:

Erstens hat man für sowas die Playlist (Showbetrieb) und zweitens ist ja wohl auch nix dabei auf STOP zu drücken bevor man eine neue Show lädt (Test/Programmierbetrieb).

Dem Prg. so viel Speicher freizuräumen, dass man mehrere Shows leichzeitig geladen hat ist ja wohl kein Punkt der auf der Prioritätenliste sehr weit oben sein wird...

Vielleicht wär es einfach nur sinnvoll ein LADEN per Dialogwindow zu verhindern wenn noch ne Show läuft! Mehr nicht. PUNKT.

Aber irgendwie wirds langsam seeehr offtopic...