AMIGA-RESISTANCE

Hallo
Und noch ein Problem
Hat schon jemand mal gemerkt das beim einsetzen von Goto, Gosub Variablenwerte verloren gehen, Variablen die schon deklariert wurden wieder verloren gehen ect. ? Bitte nun kein "NUTZE FUNCTIONEN" bitte, weil das nur noch schwerlich möglich ist. Normal kann es jedenfalls nicht sein das durch goto/gosub Werte verloren gehen.

Ist das jemand schonmal aufgefallen ?

Salli Murmel

Das sind die Momente, wo ich mir einen Debugger
wünsche. Aber leider hat das Hollywood (noch?) nicht.

Ich selber benutze die Befehle GOTO, GUSUB und LABEL
nicht.

Sind bei Dir alle Variablen global oder hast Du mal den
Befehl LOCAL benutzt?

Hast Du eine Variable auf NIL gesetzt?

Var=Nil

Versuche mal einzugrenzen, wann und wo im Code
die Variablen verloren gehen. Ich benutze dafür den Befehl Systemrequest():

Test=SystemRequest("1",Variabelname,"Ja|Nein")

Test
Das ist eine Name für eine Variable, die sonst nie in
einem Script von Dir vorkommen darf.

"1"
Irgendwie musst Du die Fenster bezeichnen, damit
Du die Stelle im Code finden kannst. Ich nummeriere
sie eben durch.

Variabelname
Da kannst Du die Variable eintippen, die sich plötzlich
verändert

"Ja|Nein"
ist nur die Beschriftung der Knöpfe

Überall, wo nun diese Systemrequest() aufgerufen werden, stoppt
das Programm und Du siehst im Fenser, ob der Wert sich
geändert hat.

Ich habe bei mir im Code schon bis zu 12 dieser Systemrequest()
eingepflanzt, bis ich den Fehler gefunden habe. Denn wenn
Funktionen andere Funktionen aufrufen, kann es immer wieder
unerwartete Nebenwirkungen mit sich bringen.

Griessli
Tipsi

Hallo Tipsi

Erstmal Danke für die Tips

Also im Code ist keine einzige Funktion. Es handelt sich um ein Schachprogramm das allerdings per Gosub Return arbeitet, und schon ca. 3 mal verschachtelt weiter im GOSUB vordringt. Der Code selber funktioniert, aber die var[0][0] Variablen scheinen spätestens in der zweiten Gosubroutine nicht mehr da zu sein. var[0][0] nicht dimensioniert, und damit sind die Daten futsch.

Also grundsätzlich ist erstmal keine Variable Local bei mir. Die einfachen Variablen sind mit Global definiert, Variablen des Typs engine[0][0][0] cmoves [0][0] können nur mit DIM (DIMSTR) definiert werden.

Also ich denke das ist ein Bug von Hollywood, weil es ja nur ein Hauptprogramm ist, müssten die Daten auch überall sein, selbst wenn mit Local definiert. Dafür gibts ja Function oder Block um mit local arbeiten zu können.

Am Abend teste ich noch mal etwas und poste etwas code.

Salli Murmel

Es ist schon möglich, dass es ein Bug in Hollywood ist.

Vielleicht ist es nur bei Deiner Hollywoodinstallation ein
Problem und bei jemand anderem läuft der Code tadellos.
Oder hast Du noch auf einem zweiten System Hollywood
installiert? Falls ja, tritt dort auch der Fehler auf?

Griessli
Tipsi

Salli Murmel

Eine andere Möglichkeit: Hast Du vielleicht irgendwo
in Deinem Code bei einem Aufruf der Array-Variable
eine Dimension zuviel oder zuwenig angegeben?

z.B. bei engine[0][0][0] nur engine[0][0]

oder bei cmoves[0][0] aus versehen cmoves[0][0][0]

Ist vielleicht die Dimension richtig, aber die Array-Variable
falsch geschrieben?

Statt engine[0][0][0] hockt im Code egine[0][0][0]
oder ähnlich?

Griessli
Tipsi

Hallo Tipsi.

Nein also die Variablen stimmen. Es handelt sich hier um eine Quickbasic Umsetzung einer spielstarken Schach-Engine.
(Allerdings war das abänderen der Vartypen ehct Horror und hat mich etzliche Stunden gekostet [][] ist echt nervig.
Die Engine selber ist also lauffähig, und es kompilierte schon Durch unter Hollywood.

Allerdings ist mir gestern die Variable CMOVES aufgefallen, und die kolidierte mit CMOVES[0][0]. Nach Umbennung in C1MOVES ist CMOVES[0][0] in der (3. Gosubverschachtelung) wieder dimensioniert.
Im Hauptprogramm war CMOVES[0][0] immer dimensioniert Also nicht leicht solche Fehler zu finden

Hollywood scheint allerdings Fehler auch zu unterdrücken, und nach beseitigung dieses Fehler meckerte HW plötzlich wieder das er keine goto/gosub ausserhalb der Hauptschleife mag.

Ich muss jetzt das Programm erst wieder neu zusammensetzen, und hoffe es hängt nicht an der Programmlänge. Normal sollten doch ca. 3200 Zeilen Code kein Problem darstellen ?

Salli Murmel

Murmel hat geschrieben:

Allerdings ist mir gestern die Variable CMOVES aufgefallen, und die kolidierte
mit CMOVES[0][0]. Nach Umbennung in C1MOVES ist CMOVES[0][0] in der
(3. Gosubverschachtelung) wieder dimensioniert.
Im Hauptprogramm war CMOVES[0][0] immer dimensioniert Also nicht leicht
solche Fehler zu finden

Super, Du hast den Fehler gefunden. Wenigstens wird es Dir nicht
langweilig.

Zitat:

Hollywood scheint allerdings Fehler auch zu unterdrücken, und nach
beseitigung dieses Fehler meckerte HW plötzlich wieder das er keine
goto/gosub ausserhalb der Hauptschleife mag.

Hollywood unterdrückt eigentlich keine Fehler. Aber der Compiler deckt immer
nur einen Fehler pro Durchgang auf und meldet sich sofort. Bei 7 Fehler musst
Du den Compiler mindestens 7 mal aufrufen.

Zitat:

Ich muss jetzt das Programm erst wieder neu zusammensetzen, und
hoffe es hängt nicht an der Programmlänge. Normal sollten doch ca. 3200 Zeilen
Code kein Problem darstellen ?

Nö, das Programm KoKa inkl. ScuiLib hat in der Zwischenzeit die Zeilenzahl
von 28'000 überschritten und wird, wenn ich keine Fehler eingetippt habe,
klaglos compiliert. Es dauert einfach ein klein wenig länger.

Griessli
Tipsi

Also ich kann nun zumindest sagen das keine Variablen verloren gehen.
Eher scheint es so zu sein das reinkopierte Codestücke teilweise wohl nicht abgearbeitet werden wenn sie nicht vorher bewegt wurden das heisst zeile runter CR.
Und ein Fehler komische Nebenwirkungen hat. z.b bei einem aus Versehen gelöschten Next schrieb er als Fehler das er keine Gosub und Returns ausserhalb der Hauptschleife mag.

Naja daran muss man sich erst gewöhnen