PXT Quelltext von GitHub anpassen

Hat sich schon jemand beschäftigt, wie man den PXT-Editor an seinen Unterricht besser anpassen kann?

Mein Ziel war es zum einen den Reset-Knopf als Start-Stop-Knopf umzubelegen, die Hilfe beim Übertragen auszubauen und eine neutrale Oberfläche zu erstellen. Beides hat ganz gut geklappt:


Dank den GitHub-Pages benötigt man keinen eigenen Webspace zum Betreiben.

Eigentlich kann man darin auch direkt Tutorials oder Aufgaben erstellen. Das klappt bei mir aber nicht, da ständig versucht wird über eine Translating-API nach der deutschen Sprache zu suchen. Das schlägt dann fehlt, da Microsoft ja mein Tutorial nicht kennt.

Der PXT-Editor benötigt zu Beginn eine Internetanbindung, da er initial aus den Quelldateien eine HEX-Datei übersetzen muss. Ist das geschafft, kann er den Nutzerquelltext anscheinend selbst integrieren. Das ist gut ersichtlich, da der übermittelte Hash immer gleich bleibt und nur beim Start erfolgt.
Was ich im Moment nicht schaffe ist, die Hex im local storage des Browsers so unterzubringen, dass diese auch gefunden wird (local storage wird vor API-Abfrage bevorzugt).
Hat das schon jemand geschafft, den Editor wirklich offline-fähig zu machen?

Hallo,

auf Grund deines Beitrags habe ich das auch mal ausprobiert und die offline Fähigkeiten getestet.
Außer einer Warnmeldung: "Du scheinst offline zu sein…"
hab ich erstmal keine Einschränkungen festgestellt.

Vielleicht liegt das daran, dass ich note.js auf einem Windows System ausführe?

Gruß
Weja

zu deiner Startknopf Frage hätte ich vielleicht eine PXT Software Lösung parat
Wenn Du das Filesystem Paket installiert, gibt es die Möglichkeit Werte persistent zu speichern.
Nun kannst Du einen Wechselschalter einrichten der abwechseld in einer leeren Warteschleife verharrt, oder das eigentliche Programm startet.

Weja

1 „Gefällt mir“

Hallo Weja,

vielen Dank für deine Antworten!

Bei dem Startknopf habe ich mich vermutlich ungünstig ausgedrückt: Das habe ich schon gelöst. Zufälligerweise auch genau wie du es vorgeschlagen hast:


Hier wird die Datei main.cpp erstellt. Der habe ich die Prüfung vorangestellt. War ein wenig anstregend zu programmieren, da die hier als String eingefügt ist.

Zu der Offline-Fähigkeit:
Gehe ich recht davon aus, dass du den Editor nicht zum ersten Mal geöffnet hast?
Der Editor benötigt nur beim allerersten Start eine Internetverbindung: Die HEX-Datei landet anschließend im Cache des Browsers und im local storage (persistenter Browserspeicher für jede Webseite).
Wenn man den Editor in einem neuen Browser öffnet oder im Privaten-Modus (ggf. mit geleerten Cache) dann erscheint zusätzlich zu der Offline-Fehlerwarnung noch ein Fehler beim Übersetzen/Herunterladen des Programmes.
Hört sich erstmal nicht so schlimm an, ist aber ungünstig, wenn der Rechner entweder noch nie am Netz war oder wie bei mir in der Schule nach jedem Neustart komplett zurückgesetzt wird.

Viele Grüße

Julian

Hi Julian,
natürlich hast du Recht. Ich hab zu dem Thema noch folgendes in der Makecode Dokumentation gefunden:

Offline editing
Web application

https://makecode… is an HTML5 web application that automatically gets cached locally by your browser. Once the web app is loaded and you have compiled at least once, you will have all the code needed to work without an internet connection.

Hier steht genau das, was du beschrieben hast. Das betrifft aber nur die Browser Webapp, eigentlich müsste doch der lokale Webserver die Start Hexdatei versenden?

Gruß Werner

Hallo Werner,
die HEX Datei wird erst auf dem Server zusammengebaut. Dabei werden anscheinend alle von der Anwendung mitgelieferten Dateien übersetzt (C-Compiler?). Auf dem Client wird dann nur noch der Quelltext des Nutzers hinzugefügt.
In meinem Fall geht die Anfrage immer an:
https://pxt.azureedge.net/compile/1cab3b123663bc16bdede1e817a7408661115365f3907d92da934ff6c2287704.hex
Die zurückgesendete Datei ist immer die gleiche. Das sieht man daran, dass der Dateiname ein lokal berechneter Hash ist.
Die zurückgelieferte HEX-Datei soll auch wenn möglich aus dem Browsercache/local storage geholt werden:


Der Quelltext an sich ist sehr hübsch geschrieben, aber ich steige einfach nicht dahinter, wie ich die Anfrage von meinem lokalen Server beantworten kann. Selbst wenn ich Zeile 3320 anpasse, kommt von einer anderen Stellle ein Verbindungsfehler. :cold_sweat:

Hallo Julian,

ich hab mir das auch mal bei PXT für den Microbit angesehen, da wird in den Webserver auch der CLI Compiler mit eingebaut. Es sieht für mich so aus, als wenn bei der pxt-Calliope-static Sache darauf verzichtet wurde.
Daher kann der Webserver das überhaupt nicht.
Auf der Client Seite hab ich mal ausprobiert bei einen Chrome-Browser mit geleerten Cache einfach das default Verzeichnis aus C:\Users%user%\AppData\Local\Google\Chrome\User Data aus einer Sicherung die die eine Online Compilation enthielt zurückzuholen. Das hat dann offline funktioniert.

Gruß
Werner

Hallo Werner,
meinst du der CLI Compiler liese sich bei dem Calliope Webserver mit integrieren?
Verstehe ich das richtig, dass du die Online Compilation manuell verschoben hast oder hast du die mit den lokalen Webserver integriert?

Viele Grüße, Julian

Hallo,

Ich denke dass sich das machen lässt eine vollständige lokale Instanz des Calliope Webservers zu installieren. Schließlich funktioniert das scheinbar bei dem microbit auch.
Aber ich habe keine Ahnung von dem Zeugs und muss mich da auf andere verlassen.
Ja das Verzeichnis habe ich manuell verschoben. Kann man ja aber auch mit einm Script machen.

Gruß

Hat jemand von euch schon mit dem nun neuen freigegebenen aktualisierten pxt-calliope github repository gearbeitet?

Zuerst habe ich bei mir die python Versionen einiger für yotta nötigen Pakete anpassen müssen
pip install pip==9.0.3
pip install pyopenssl==17.5.0
pip install cryptography==2.1.4
, da die Windows-Yotta Installation pip auf einen zu hohen Stand aktualisiert hatte.

Dann mußten auch die Pfade für die im Windows-Yotta Paket enthaltenen
ninja , cmake und gcc richtig gesetzt werden.

Und die Dokumentation auf “https://makecode.com/cli
weist auch noch auf die Notwendigkeit der richtigen
Installation von SRecord(“https://sourceforge.net/projects/srecord/files/srecord-win32/1.64/”)
hin.

Auch der Anleitung unter “https://github.com/Microsoft/pxt-microbit” für das
Bauen von pxt mußte ich genau folgen, damit ich
dann später “pxt staticpkg” verwenden kann.

Insbesondere sind eben die typings erst durch das Festlegen
auf den Branch “v0” verfügbar.

npm install -g jake
npm install -g typings

git clone https://github.com/microsoft/pxt
cd pxt
git checkout v0

npm install
typings install
jake
cd …/

git clone https://github.com/microsoft/pxt-calliope
cd pxt-calliope

npm install -g pxt
npm install
npm link …/pxt

Wenn man in “pxt-calliope\docs\js\inference.md”
auch noch etwas Text z.B. “#Type Inference”
einfügt dann läuft auch das Ausführen
von “pxt staticpkg” ‘Fehlerfrei’ ab.

Allerdings Läuft dann im mit
dem auf “build/packaged”
gestarteten “npm http-server”
genau das Oben von Euch beschriebene
Compilieren bzw. Zusammensetzen der HEX Dateien
oder eben auch “Herunterladen” nicht.

Der Server meldet irgendwie immer
“POST /compile/extension” Error (404): “Not found”
und liefert eben keine hex-Datei.

Mit “pxt serve” kann ich allerdings einen lokalen
dann auch weitestgehend fünktionierenden Server starten.

Der hat allerdings in der Adress-Zeile eine andere
etwas komplexere Struktur.

Hat jemand eine Ahnung wo da was schief läuft?

Wird die obige Funktion im static-Server überhaupt
gestartet? Wenn ja wo scheitert sie?
Wenn nein warum nicht? Muß man da noch etwas
konfigurieren?

Danke für vielleicht etwas mehr Einblicke.

Mfg

Andreas

2 „Gefällt mir“