+- AmiBlitz³ (https://www.amiblitz.de/community)
+-- Forum: AmiBlitz³ (https://www.amiblitz.de/community/forum-3.html)
+--- Forum: AB³ Development (https://www.amiblitz.de/community/forum-16.html)
+--- Thema: Umgebungsvariablen des RedDebugers (/thread-130.html)
Re: Umgebungsvariablen des RedDebugers - tomsmart1 - 31.01.2015
@Blackbird
ich habe nichts gemacht und warte auf Bernd
Berndroesch schrieb:im original source ist dann 8f4e also für local vars. ich copiere die old source labels und kommentare im neuen source dazu. komisch wieso er in der globalen liste sucht. unten bei .hendrix sucht er in der localen. naja muss man mit testprogram ausprobieren, wie es genau funktioniert
macht er also auch im originalsource, dass er für locale vars in der globalen liste sucht. wahrscheinlich ist varbase die Liste der globalen variablen und firstglob die liste der shared variablen die auch in einer funktion gelten
Ich habe es mir jetzt auch mal genau angesehen ich sehe es genauso firstglob ist die Liste der globalen Variablen (shared), firstlocal die Liste der Lokalenvaribalen für Funktion/Statement und firstvar die Liste der Variablen die nicht geteilt (not shared) werden des Programmes. Procmode enthält die Information ob die Runktion (fetchvar) aus dem Hauptprogramm oder einer Funktion/Statement aufgerufen wurde.
Re: Umgebungsvariablen des RedDebugers - tomsmart1 - 05.02.2015
@All
Geänderter und gefixter Debugger ist jetzt commited mit R519.
@Bernd
Bist du schon weiter gekommen ?
Ich habe hier angefangen die Labelnamen und Kommentare aus dem Original Sourcecode zu übernehmen momentan habe ich die Funktionen do_dim, do_deftype, do_shared sowie fetchvar bearbeitet habe auch Makierungen eingefügt ("; new >", "; > new") für Codeteile die im Orginal nicht vorhanden sind zu besseren übersicht. Die Sprunghelfer für Fehlermeldungen in diesen Funktionen habe ich hinter das ender de jeweiligen Funktion verschoben.
Re: Umgebungsvariablen des RedDebugers - Berndroesch - 23.02.2015
Zitat:Seit ihr schon weitergekommen wegen den Variablencheck in Functions und Statements ?
ist etwas nervig wenn man seinen Source nicht kompilieren kann
war das Problem mit dem cacheclearE ?. und gehts jetzt ?
Re: Umgebungsvariablen des RedDebugers - tomsmart1 - 25.02.2015
Nein das denke ich nicht da das cacheclearE Problem gelöst ist, ich gehe davon aus das er perfect paint mit dem einfachen Variablecheck für DEm bze vieleicht auch for Deftype nicht compileren kann.
Re: Umgebungsvariablen des RedDebugers - tomsmart1 - 20.03.2015
Mit Bernds hilfe checkt DIM ab Revision 542 jetzt ob die Varaiable bereits benutzt wird ob gobal oder lokal wird unterschieden und gibt dann entsprechen eine Fehlermeldung aus.
Re: Umgebungsvariablen des RedDebugers - Der Wanderer - 23.03.2015
Sehr schön, Danke!
P.S.: Als jemand der Amiblitz3 täglich bei der Arbeit (!) nutzt, weiss ich euer Engagement zu schätzen. Wenn der Arbeitsdruck wieder etwas nachlässt helfe ich auch wieder mit.
Re: Umgebungsvariablen des RedDebugers - Berndroesch - 24.03.2015
habe ich mir die arbeit wohl umsonst gemacht. dass sowas richtig geht, weil die vars in unterschiedlichen Listen stehen wusste ich garnicht. damit ein fehler kommt, müsste man alles in dieselbe Liste tun. scheinbar hat dann blitz2 extra listen für stringvars,arrays und normale vars, oder es generiert den variablen namen nicht richtig, was ich eher vermute. array legt es vielleicht +( an also: mem als array heist dann in der Liste mem( oder string heist dann mem$
. Wenn man das behebt, müsste der dann auch meckern. aber wenn der compiler meckert, wäre dass dann ein komplett anderer syntax mode, weil alte Programme die vorher liefen dann angemeckert würden. das prog funktionert(alter compiler), da sieht man es werden unterschiedliche variablen genommen
Syntax 2
DEFTYPE .l mem
Dim mem.s(200)
mem=20
mem(1)="test"
mem$="test$"
NPrint mem output: 20
NPrint mem(1) output: test
NPrint mem$ Output: test$
Re: Umgebungsvariablen des RedDebugers - tomsmart1 - 25.03.2015
@Bernd,
es hat niemand gesagt das der Compiler ein Problem hat sie auseinander zu halten. Es geht nur um den User das der den Überblick behält.
Es muss auch an den verschiedenen Listen die der Compiler dafür verwaltet nichts geändert werden. Es muss auch keine Fehlermeldung kommen das der Variablename bereits benutzt wird für test.l zu test$ oder test() to test$ dieser Unterschied ist für den Benutzer sofort auf einen Blick erkennbar am "$".
Problematisch sind test$ und test$() für den Benutzer, sowie bei den andern Typen wenn im späteren Verlauf des Progamms der Type wie .l, .w, .b, .s weggelassen werden kann oder wird.
Es ist ein altes Problem das mindestens seit Blitzbasic 2 besteht und DIM hat wie ich festgestellt habe ja auch keinen zwang einen Typ für den Array vorzugeben was jedenfalls mal denke ich ab Syntax 2 Pflicht sein sollte.
Deine Routine checkdoubledeclare ist super sie bringt uns eine großes Stück voran, dafür Danke ich dir und ich denke die anderen auch.
Ok ich habe jetzt zwei Punkte gefunden wo sie nicht so funktioniert aber das ist kein großes Problem wir müssen sie nur etwas erweitern für den Fall das der Typ nicht mit "." hinter dem Variablenamen anfängt.
Und für das Problem das es zu streng für alten Sourcecode ist wäre ja die Möglichkeit die checkdoubledeclare Routine erst ab z.B. Syntaxlevel 2 durchlaufen zu lassen.
Re: Umgebungsvariablen des RedDebugers - Berndroesch - 25.03.2015
Das Problem worum es ging war, dass der code
DEFTYPE .l mem
Dim mem.s(200)
keine Fehlermeldung bringt. Ich gebe ja keinem die Schuld, ich bin selber schuld wenn ich da nicht nachgeprüft habe, ob es in dem Compiler geht oder nicht. von daher brauchste auch nicht es als notwendig schönreden
Fürs programmieren wird die ungarische Notation vorgeschlagen, wegen der Übersichtlichkeit. windows hat das in Variablennamen
<!-- m --><a class="postlink" href="http://de.wikipedia.org/wiki/Ungarische_Notation">http://de.wikipedia.org/wiki/Ungarische_Notation</a><!-- m -->
dabei soll man den variablentyp als name zur besseren übersichtlichkeit davorschreiben. eutzutage hat man einen variablen browser, da kann man nachschauen, wenn etwas nicht geht. Zumindest erzeugt blitz keinen falschen Code wie ich anfangs gedacht hatte.
Ich bin nämlich einfach davon ausgegangen, dass das nicht geht. So wie es jetzt aussieht, wird in der variablenliste bei addvariable tatsächlich 2 mal eine variable mit namen mem in derselben Liste angelegt. die haben auch verschiedene offsets. nur wieso findet der Compiler dann die richtige, wenn 2 in der Liste stehen. da muss ich also den Code finden, der beim variablen suchen, die richtige
findet. und der code den ich neu gemacht habe, mag zwar zu 99.9% funktionieren, ist nur ein workaround. und besser ist die Ursache zu finden
denn der Code erzeugt einen Fehler(ohne meinen neuen Code). da checkt also dim schon ob es die Variable desselben types schon gibt, im originalcode
Dim mem.s(200)
Dim mem.l(200)
also muss der extra code in blitzbasic drinhaben, damit es erlaubt ist, 3 Variablen mit selben Namen zu haben, array, normal, strings.
vielleicht ist das so in der basic spezifikation festgelegt. man müsste mal schauen wie das bei anderen basic interpretern oder compilern funktioniert. vielleicht hat mal jemand genug Zeit und kann es mal probieren
Re: Umgebungsvariablen des RedDebugers - tomsmart1 - 26.03.2015
Es ist geschafft ich habe jetzt alle DisAsm Labelnamen in die litzbasic2 sourcecode Labelnamen geändert und die orginal Kommentare eingefügt, puh
Wenn ich mir den source jetzt ansehe vor allem die Routinen fvarfound, fvaradd, typemode und getparameter da wir immer der type in "flagmask" codiert jedenfals mal fürs suchen. Daher denke ich das der Typ beim anlegen des Variabelnames in der Liste vom Compiler eincodiert wird.