Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
Umgebungsvariablen des RedDebugers
#1
Hallo Mitentwickler,

nach kurzer aber energischer Diskussion konnte ich leider auch für Ab3 feststellen das wir die Variablen
für den RedDebugger fälschlicherweise einfach in Envarc: abspeichern !
Das entspricht weder den Styleguides noch dem neuen Credo das Ab3 Standalone laufen soll.

Das Progdir: sollte als Speicherort gewählt werden., sodas man einfach den Ab3 Ordner kopieren kann wie/wohin man will.
auffällig wird das ganze wenn man sein System mal neu installieren muß. Programmdateien haben nichts, aber auch gar nichts
in Envarc zu suchen.

das sollten wir demnächst angehen ! kann nicht schwierig sein das umzumodeln...
Zitieren
#2
So, ich habe den Speicherplatz für die Vars nun auf Blitz3Big Grinebug geändert, der Pfad dürfte immer gültig sein wenn man den Debugger aus AB3 aufruft...

Frage:
War der Debugger jemals dafür gedacht auch für ander Sprachen einsetzbar zu sein als Ab3 ?
Ich frage deshalb, weil im Debugger nochmals die Librarys abgefragt werden die beim start von Ab3 über PED doch schon abgedeckt werden.
Eine nochmalige Abfrage macht doch da dann gar keinen Sinn....
Zitieren
#3
Frage, sollte der Compiler nicht bei sowas meckern bei
optimize 5 ; don't use fpu because all calc must in FFP!!!!
Syntax 6

wenn:

DEFTYPE.l mem

und etwas später im Source dann:

Dim mem.s(200)

steht ?

Sowas in der Art wie: Variable bereits deklariert oder Types Mismatch ?????

und weiter

ich habe im Source noch einige Stellen mit Val() entdeckt, die sollten wohl gegen Vallong ersetzt werden und sind vergessen worden oder ?
Zitieren
#4
Blackbird schrieb:Frage:
War der Debugger jemals dafür gedacht auch für ander Sprachen einsetzbar zu sein als Ab3 ?
Ich frage deshalb, weil im Debugger nochmals die Librarys abgefragt werden die beim start von Ab3 über PED doch schon abgedeckt werden.
Eine nochmalige Abfrage macht doch da dann gar keinen Sinn....

Die Abfrage habe ich ganz am anfang mal eingebaut als Sicherheitsfunktion. Man kann auf jedenfall den Debugger auch alleine starten ob da aber was funktioniert keine Ahnung da doch große Teile vom Compiler direkt abhängig sind.

Blackbird schrieb:Frage, sollte der Compiler nicht bei sowas meckern bei
optimize 5 ; don't use fpu because all calc must in FFP!!!!
Syntax 6

wenn:

DEFTYPE.l mem

und etwas später im Source dann:

Dim mem.s(200)

steht ?

Huch das ist nicht gut und da sollte der Compiler meckern!

Ps: Habe es gerade ausprobiert er meckert erst bei der ersten Verwendung von mem als String bei:
Code:
prt.l=&mem(ypos)
das er den Type nicht konverieren kann.

Edit:20.01.15 kleine Korrektur.
Zitieren
#5
Habe die Änderungen schon vorgenommen und alle Val auf Vallong, sowie den Check auf die libs rausgenommen.

Ja, der Debugger meckert erst bei dieser Stelle, deshalb frag ich ja warum er das nicht schon früher macht Wink
Zitieren
#6
Blackbird schrieb:Habe die Änderungen schon vorgenommen und alle Val auf Vallong, sowie den Check auf die libs rausgenommen.
Ish weiß es jetzt nicht mehr genau aber ist da nicht irgendwo eine Eingabe von Gleitkommazahlen vorgesehn dafür muss man VAL benutzen.

Blackbird schrieb:Ja, der Debugger meckert erst bei dieser Stelle, deshalb frag ich ja warum er das nicht schon früher macht Wink
Ja da sollte der Compiler bei DIM mem.s(200) Alarm schlagen, das ist was für Bernd.
Zitieren
#7
Ah ok, habe jetzt nicht weiter geschaut wegen Val, dann bau ich das wieder zurück bis wir das geklärt haben...

Schreibst du Bernd mal an was da los ist und ob er helfen kann ?
Zitieren
#8
Blackbird schrieb:Frage, sollte der Compiler nicht bei sowas meckern bei
optimize 5 ; don't use fpu because all calc must in FFP!!!!
Syntax 6

wenn:

DEFTYPE.l mem

und etwas später im Source dann:

Dim mem.s(200)

steht ?

Sowas in der Art wie: Variable bereits deklariert oder Types Mismatch ?????

und weiter

ich habe im Source noch einige Stellen mit Val() entdeckt, die sollten wohl gegen Vallong ersetzt werden und sind vergessen worden oder ?

wegen dem dim.s , da fehlt ne abfrage. ich habe nur auf den source geschaut, müsst testen ob es geht.

JL_0_E11E:
CLR.w nonew
JSR getparameter
+BSR findtype
+BEQ.w error_type schon deklariert

und wegen der error message das passende einsetzen
ist noch ein übler BB2 Bug

selbst dinge wie

mem.l =20
Dim mem.s(200)

bringen keinen Fehler, weil der dim befehl erst garnicht prüft ob die Variable schon da ist
Zitieren
#9
@Bernd

ich habe es getestet es gibt da leider auch keine Fehlermeldung bei umgekehrter Reihenfolge gibt es dann ein Read Hit in findtype auf 0.
Zitieren
#10
Ahhhh Bernd ist wieder da Big Grin

Ok, na das hört sich ja gar nicht gut an, gut das ich darüber gestolpert bin...

Mal sehen was dann alles zm vorschein kommt bei alten Sourcen wenn ihr das gefixt habt :?
Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 16 Gast/Gäste