ROBO Pro Coding: Gobale Variablen zwischen Quellcode-Dateien austauschen?

Alles rund um TX(T) und RoboPro, mit ft-Hard- und Software
Computing using original ft hard- and software
Forumsregeln
Bitte beachte die Forumsregeln!
Antworten
Benutzeravatar
MINT-Matthias
Beiträge: 7
Registriert: 16 Apr 2022, 23:55
Wohnort: Oberursel
Kontaktdaten:

ROBO Pro Coding: Gobale Variablen zwischen Quellcode-Dateien austauschen?

Beitrag von MINT-Matthias » 25 Apr 2022, 21:41

Hallo zusammen,

neben dem aktuellen Boot-Bug in der ROBO Pro Coding App Version 6.0.10 (siehe anderes Forumsthema) kämpfe ich momentan mit
folgender Problematik:
* Bei der Blocky-Programmierung scheinen alle in den selbst-geschriebenen Funktionen eingeführten Variablen als Global definiert zu sein.
Man kann auf diese Variablen beispielsweise in der Main-Schleife oder in anderen selbst-programmierten Funktionen mühelos zugreifen.
So weit, so gut!
* Um die Blocky-Programmierung großer Projekte übersichtlich zu gestalten, füge ich meine eigenen Funktionsdefinitionen jeweils in eine neue
"Quellcode-Datei" ein. Auf der Python-Ebene bedeutet jede neue Quellcode-Datei (mit Namen "xxx") ein neues Modul mit Namen "lib.xxx",
welches dann am Anfang der Hauptprogramm-Datei (main.py) importiert wird (Befehl: "from lib.xxx import *"). So weit, so gut!
* Aber: Im Hauptprogramm (main.py) definierte (globale) Variablen sind in den selbst-definierten Funktionen, welche in der separaten
Quellcode-Datei (mit Namen "xxx") abgelegt sind, nicht benutzbar.
* Und auch andersherum kann man aus dem Hauptprogramm nicht auf die (globalen) Variablen zugreifen, welche in den eigenen Funktionen,
(abgelegt in der separaten Quellcode-Datei mit Namen "xxx") definiert wurden.
* Das heißt, dass man bei einer selbst-definierten Funktion in der Hauptprogramm-Datei zwar auf alle (globalen) Variablen der Main-Schleife
zugreifen kann, dies aber nicht möglich ist, wenn die gleiche Funktion in einer eigenen Quellcode-Datei mit Namen "xxx" liegt.

Weiß jemand hierzu eine Lösung?

In der "regulären" Python-Dokumentation habe ich diese Problematik bereits entdeckt. Dort wird empfohlen, anstelle des "from lib.xxx import *"
Befehls die andere Variante "import lib.xxx" zu verwenden, wodurch man dann auf alle globalen Modul-Variablen unter dem jeweiligen
(erweiterten) Namen "lib.xxx.variablenname" zugreifen kann. In der ROBO Pro Coding App wird jedoch beim
Blocky-to-Python-Übersetzungsalgorithmus der "from lib.xxx import *" Befehl verwendet,
welchen man in der Blocky-Umgebung nicht ändern kann.

Danke für Euren Input zu diesem Thema, Matthias.

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: ROBO Pro Coding: Gobale Variablen zwischen Quellcode-Dateien austauschen?

Beitrag von MasterOfGizmo » 09 Mai 2022, 15:58

Generell ist die Nutzung globaler Variablen in Python etwas eigenartig gelöst und es gibt m.E. eigentlich keinen Grund, in Python überhaupt globale Variablen zu verwenden. Das kollidiert aber etwas mit der Tatsache, dass in Blockly alle Variablen global sind, selbst Funktionsparameter. Das wiederum führt häufig zu eher unschönem Blockly-generiertem Python-Code, der vor allem wenig Wert als Lernmaterial hat.

Du kannst das mit diesen Spezialblöcken umgehen/erzwingen:
importnase.png
importnase.png (35.35 KiB) 1336 mal betrachtet
Damit kannst Du im externen Modul "nase" die globale Variable "abc" setzen und die wird dann dort sichtbar und z.B. in der Funktion "machwas" nutzbar.

Aber das hat dann irgendwann keinerlei ästhetischen Wert mehr. In der Schule/zur Ausbildung nutzen kannst Du das nicht. Das ist technisch so schlimm, dass jeder Lehrer, der das nutzt, sofort strafversetzt wird.

Aber was hindert Dich daran, auf globale Variablen an der Stelle vollkommen zu verzichten? Du kannst doch der externen Funktion beliebige Variablen ganz regulär übergeben.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: ROBO Pro Coding: Gobale Variablen zwischen Quellcode-Dateien austauschen?

Beitrag von MasterOfGizmo » 09 Mai 2022, 16:39

Das geht auch alles noch viel dreckiger. Du kannst die Python-Blöcke auch nutzen, um den Blockly-generierten Code auszukommentieren:
kommentar.png
kommentar.png (35.42 KiB) 1314 mal betrachtet
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

vleeuwen
Beiträge: 1557
Registriert: 31 Okt 2010, 22:23
Wohnort: Enschede (NL)
Kontaktdaten:

Re: ROBO Pro Coding: Gobale Variablen zwischen Quellcode-Dateien austauschen?

Beitrag von vleeuwen » 09 Mai 2022, 16:46

Global variables with getters and setters in a RoboPro library with Blocklies, easy to share and to use in other modules:
Globale Variablen mit Gettern und Settern in einer RoboPro-Bibliothek mit Blocklies, einfach zu teilen und in anderen Modulen zu verwenden:
GlobalVars.JPG
GlobalVars.JPG (81.08 KiB) 1313 mal betrachtet
software enigineer/teacher/advisor
Google translate
http://tescaweb.nl/Carel/?p=713

Benutzeravatar
MINT-Matthias
Beiträge: 7
Registriert: 16 Apr 2022, 23:55
Wohnort: Oberursel
Kontaktdaten:

Re: ROBO Pro Coding: Gobale Variablen zwischen Quellcode-Dateien austauschen?

Beitrag von MINT-Matthias » 11 Mai 2022, 18:01

Vielen Dank für Eure ausführlichen Antworten mit den guten Tipps.

Gerne würde ich meine Fragestellung nochmals an folgendem Beispiel motivieren und veranschaulichen:
* In meinen MINT-AGs bauen Schülerinnen und Schüler (Klasse 5-7, zunächst ohne (!) Programmiererfahrung)
ft-Modelle (beispielsweise Rover oder Modell-Fabrik) und verbinden diese u.a. mit TXT4.0 Controllern.
Danach steht für diese Kinder ihre erste (!) Programmierung an. Dabei möchte ich zunächst nur in der Blocky-Umgebung
arbeiten; zu diesem Zeitpunkt auch noch ohne Python-Code-Importe.
* Schritt 1: Die SchülerInnen geben eine Folge von einzelnen Blocky-Kommandos im "Main Program" ein, um beispielsweise
Teilkomponenten des Rovers zu steuern.
* Schritt 2: Die Messwerte der (vielen!) verbauten Sensoren werden in Variablen (im Hauptprogramm) gespeichert.
Aufgrund der Vielzahl der Sensorwerte entsteht so eine große Menge an "einzelnen" Variablen
(beispielsweise "main-var08" in untigem Beispiel). Eine Variablen-Liste wird dabei (noch) nicht erstellt.
* Schritt 3: Mit diesen vielen Variablen werden verschiedene Operationen (die späteren Funktionen) durchgeführt.
Dabei werden viele der bislang definierten Variablen verwendet und geändert.
* Schritt 4: Jetzt stellen die TeilnehmerInnen fest, dass das Hauptprogramm sehr umfangreich und lang wird,
u.a. weil die Blocky-Befehle (auf der Seite "Main Program") sehr viel Platz einnehmen. Daher werden (für sich
wiederholende Operationen) Blocky-Funktionen eingeführt, die zunächst auch auf der "Main Program" Seite
liegen und aus dem Hauptprogramm heraus an verschiedenen Stellen aufgerufen werden können.
* Schritt 5: In den jeweiligen Funktionsdefinitionen werden auch neue Variablen eingeführt (beispielsweise "func-var08" in untigem Beispiel).
* Aufgrund der Tatsache, dass alle Blocky-Variablen als Global (in Python) betrachtet werden, haben sowohl
das Hauptprogramm als auch alle Funktionen Zugriff auf alle Variablen. Das anhängende, einfache Beispiel illustriert dies.
* Es ist mir vollkommen klar, dass bei einer "Erwachsenen-Programmierung" hier eine saubere Variablenübergabe und
-rückgabe an die Funktionen erfolgen müsste, so dass man in diesem Fall alle verwendeten Variablen als Lokal deklarieren
könnte/sollte. Jedoch möchte ich dieses "höhere Programmierkonzept: Lokal-Global" den Kindern (an dieser Stelle) noch nicht
vermitteln. Zudem würde eine komplette Übergabe und Rückgabe der vielen Variablen an die Funktionen in Blocky einen großen
Konfigurieraufwand bedeuten, der wiederum viel Platz auf dem Arbeitsblatt benötigen würde. Alternativ könnte man dies auch
mit Variablen-Listen oder gleich mit Objektorientierung realisieren, aber dies finde ich an dieser Stelle zu aufwändig und zu
kompliziert für die Teilnehmenden. Darüber hinaus sprengen diese Ansätze bereits die Möglichkeiten der Blocky-Programmierung.
* Insofern finde ich es gut, dass alle Blocky-Variablen Global sind und man damit zwar einen nicht sauberen, aber
dafür einfachen, pragmatischen Weg gehen kann.
* Jetzt komme ich zu "meinem Knackpunkt": Wenn man nun aufgrund von Platzmangel auf dem "Main Programm"-Arbeitsbereich die
Funktionen in eine neue Seite (New Source Code) "ausquartiert", dann funktioniert dieser Weg des einfachen Austausches
(globaler) Variablen zwischen dem Hauptprogramm und den "ausquartierten" Funktionen nicht mehr, denn in den Funktionen kann man
nicht mehr auf die im "Main Program" definierten Variablen zugreifen und umgekehrt geht es auch nicht mehr. Die Variablen werden
einem in der jeweiligen Blocky-Umgebung nicht mehr zur Auswahl angezeigt. Und das hat anscheinend mit der
(hinter der Blocky-Umgebung stehenden) Python-Übersetzung zu tun (siehe mein erster Beitrag).
* Wenn es aber dafür keine einfache (im Sinne der Teilnehmenden) Lösung geben sollte, wäre an diesem Punkt für mich das Ende der
Blocky-Programmierung in meinen Schul-AGs erreicht und ich müsste mit den Teilnehmenden ab dieser Stelle den Schritt in Richtung
direkter Python-Programmierung gehen.

Diese etwas länglichen Ausführung zum Hintergrund und zur Motivation meiner Fragestellung.

Danke für Eure erneuten Rückmeldungen.

Hier noch das oben beschriebene, einfache Beispiel:
Dateianhänge
Example1.jpg
Example1.jpg (58.9 KiB) 1215 mal betrachtet

Benutzeravatar
MasterOfGizmo
Beiträge: 2720
Registriert: 30 Nov 2014, 07:44

Re: ROBO Pro Coding: Gobale Variablen zwischen Quellcode-Dateien austauschen?

Beitrag von MasterOfGizmo » 12 Mai 2022, 10:39

Ich denke nicht, dass das was Du möchtest machbar ist. Mit den beschriebenen Krücken ja, aber das ist wie Du ja selbst sagst dann genau das Gegenteil der Vereinfachung, die Du für die Schüler gern hättest.

So 100% mag ich ja nicht zustimmen, dass es didaktisch sinnvoll ist, auf diese Weise zu vereinfachen. Das führt zu diesen "wir machen das erstmal so, aber in Wirklichkeit würde man das anders machen"-Momenten.

Dass Du nur Variablen aus dem aktuellen Block-Editor-Fenster siehst und nutzen kannst hat übrigens nix mit Python zu tun. Das ist eine Eigenart von Blockly. Es ist schlicht in Blockly nicht vorgesehen, Programme aus mehreren Fenstern zu nutzen. Was fischertechnik da macht ist deren eigene Idee, Blockly zu nutzen. Aber mit Python hat das in dem Moment nichts zu tun. Mit Python bekommt Blockly erst zu tun, wenn der Code exportiert wird. Erst dann wird ein Blockly-Codegenerator angeworfen, der aus der Blockly-internen Darstellung Python erzeugt. Aber während Du Dein Programm entwirfst weiss Blockly noch nichts davon, dass es dabei mal um Python gehen soll. Dass es auf der rechten Seite eine Live-Anzeige des Python-Codes gibt ändert daran wenig. Da ruft fischertechnik halt explizit immer mal wieder den Python-Code-Generator auf. Aber einen Einfluss auf das was im Block-Editor passiert hat das nicht.
Arduino für fischertechnik: ftDuino http://ftduino.de, ftDuino32 http://ftduino.de/32

Antworten