Wenn man in Squeak 4.1 von einem "Kachelskript" zur Textversion des Skripts übergehen will, kommt die Fehlermeldung: "DoesNotUnderstand: #makeIsolatedCodePaneClassSelector:". Was lässt sich dagegen tun?
Mit Dank füpr die Hilfe R. Baumann
Lieber Rüdeger Baumann,
On Thu, 15 Jul 2010, R. Baumann wrote:
Wenn man in Squeak 4.1 von einem "Kachelskript" zur Textversion des Skripts übergehen will, kommt die Fehlermeldung: "DoesNotUnderstand: #makeIsolatedCodePaneClassSelector:". Was lässt sich dagegen tun?
Vermutlich im Bug-Tracker ein Ticket eröffnen. Da kenne ich mich aber nicht so genau aus.
Ich selber habe früher auch daran gedacht, genau diesen Weg zu gehen: Kachel-Programmierung mit Etoys und dann durch die Falltüre 'Textversion des Skriptes' hinab in die Tiefen von Smalltalk.
Bis ich dann irgendwann darauf gestoßen bin, wie trickreich die Klasse 'player' gemacht ist.
So gesehen vielleicht folgender Rat: Je nach Einsatzzweck sind verschiedene squeakbasierte Images im Umlauf. Spontan fällt mir ein: Etoys, Squeak4.1, Seaside, Pharo (da weiß ich jetzt nicht genau, ob ich mir Kritik einfange, wenn ich das als squeakbasiert aufliste - mea culpa, die Hintergrunddetails habe ich nicht voll parat).
Pharo hat seinen Ursprung genau in dem Problemfeld, zu dem wohl auch ihr Problem gehört: Squeak4.1 ist im Laufe der Jahre gewachsen, es enthält sehr viele Dinge, die unterschiedlich gut funktionieren. Die Entwickler von Pharo haben hier erst einmal ordentlich entschlackt und nur das darin gelassen, was in ihren Augen wichtig und gut gemacht ist. So sollte man in Pharo wohl weniger Überraschungen erleben dürfen als mit Squeak4.1. Was mich selber für mein Einsatzszenario Unterricht stört, ist zum einen die etwas umständliche Klickkombination, um an das Halo eines Objektes zu kommen, zum anderen das Fehlen von 'Projekten' als unterschiedliche Sichten auf die Arbeitsoberfläche.
Was es in Pharo z.B. überhaupt nicht gibt, sind die Etoys. Dafür gibt es aber das Etoys-Image von Squeakland bzw. OLPC. Dieses Image legt seinen Fokus auf die Kachelprogrammierung. Von daher würde ich zum Kachelprogrammieren und allem, was im Kern damit zu tun hat, auch nur dieses Image benutzen.
Konkret: 1. Kachelprogrammieren für die Kleinen:
Etoys-Image, wie es ist
2. Übergang zu Smalltalk im Sinne von Entdecken der Squeak-Entwicklungsumgebung und der Klassenhierarchie:
Etoys-Image, ggf. mit Alt-W oder Alt-, ein Weltmenü öffnen, unter Hilfe den Einstellungsmanager öffnen, dort nach 'friendly' suchen und etoysfriendly deaktivieren - und das Image speichern. Dann kommt man einfach an Browser, Workspace und Inspektoren. Bei Bedarf kann man auch die Standard-Entwicklerklappen installieren. Noch hat man dann ein Squeak3.x-Image (stimmt das, Bernd?).
3. Richtiges Smalltalk-Programmieren:
Aus dem Bauch würde ich am liebsten Pharo nehmen, werde aber vielleicht doch bei Squeak4 landen - vor allem wegen der Projekte, evtl. auch, weil man dort einfach einen Knopf aus dem Objektkatalog ziehen kann. Da wären mir Syntaxfärbung und -vervollständigung wichtig.
Wenn ich zwischendurch konzeptionelles mit den Kacheln zeigen will, kann ich ja auf das Etoys-Image zurückgreifen. Was ich da nie einfach geschafft habe, war, aus etwas mit Kacheln programmiertem eine Unterklasse zu erzeugen. Aber davon habe mich ohnehin verabschiedet, weil das Programmieren der Morphe auch in Smalltalk nicht wirklich schwierig ist, wenn man die entscheidenden Nachrichten gefunden hat.
Markus
Vielen Dank für die hilfreichen Bemerkungen. Noch einige Fragen bzw. Bemerkungen.
Ich selber habe früher auch daran gedacht, genau diesen Weg zu gehen: Kachel-Programmierung mit Etoys und dann durch die Falltüre 'Textversion des Skriptes' hinab in die Tiefen von Smalltalk.
Sehr gut - es ist der "Königsweg" Smalltalk!
Bis ich dann irgendwann darauf gestoßen bin, wie trickreich die Klasse 'player' gemacht ist.
Was soll eigentlich die Theatermetaphorik (player, costume etc)? Wo kommt das her, wer hat das aufgebracht?
Die naive Vorstellung ist: Es gibt Objekte und Skripten; letztere dienen dazu, den Objekten vorzu"schreiben", was diese zu tun haben. Was sollen in diesem Zusammenhang "Spieler" und "Kostüme"?
Übergang zu Smalltalk im Sinne von Entdecken der Squeak-Entwicklungsumgebung und der Klassenhierarchie:
Etoys-Image, ggf. mit Alt-W oder Alt-, ein Weltmenü öffnen, unter Hilfe den Einstellungsmanager öffnen, dort nach 'friendly' suchen und etoysfriendly deaktivieren - und das Image speichern. Dann kommt man einfach an Browser, Workspace und Inspektoren. Bei Bedarf kann man auch die Standard-Entwicklerklappen installieren. Noch hat man dann ein Squeak3.x-Image (stimmt das, Bernd?).
Das scheint mir zu umständlich.
Wenn in Squeak 4.1 der Weg von der Kachel- zur Textversion eines Skripts verschüttet ist, muss ich eben bei Squeak 3.9 bleiben. Vielleicht schaufelt die Entwicklergemeinschaft den Weg ja auch wieder frei.
Wenn ich zwischendurch Konzeptionelles mit den Kacheln zeigen will, kann ich ja auf das Etoys-Image zurückgreifen. Was ich da nie einfach geschafft habe, war, aus etwas mit Kacheln Programmiertem eine Unterklasse zu erzeugen.
Was heißt das? Wozu wird das benötigt?
Aber davon habe mich ohnehin verabschiedet, weil das Programmieren der Morphe auch in Smalltalk nicht wirklich schwierig ist, wenn man die entscheidenden Nachrichten gefunden hat.
Aber die erst einmal finden, ist doch das Problem.
Viele Grüße
R. Baumann
On 19.07.2010, at 01:31, R. Baumann wrote:
Bis ich dann irgendwann darauf gestoßen bin, wie trickreich die Klasse 'player' gemacht ist.
Was soll eigentlich die Theatermetaphorik (player, costume etc)? Wo kommt das her, wer hat das aufgebracht?
Da müsste man die Leute fragen, die es gebaut haben. Auf der Squeaklandliste.
Die naive Vorstellung ist: Es gibt Objekte und Skripten; letztere dienen dazu, den Objekten vorzu"schreiben", was diese zu tun haben. Was sollen in diesem Zusammenhang "Spieler" und "Kostüme"?
In erster Näherung sind es tatsächlich nur Objekte und Skripte.
Bei genauerer Betrachtung verstecken sich 2 Smalltalk-Objekte hinter jedem "Etoys-Objekt": Ein Player für das Verhalten, und ein Morph für das Aussehen. Den Morph sieht man auf dem Bildschirm, der Player hat die Skripte.
Softwaretechnisch gesehen implementiert der Player ein prototypen-basiertes System (im Ggs. zum klassen-basierten Smalltalk). Methoden werden einem Objekt hinzugefügt, mit Klassen muss man sich als Etoysnutzer nicht befassen (die Klasse ist immer Player). Man kann einfach ein Objekt kopieren und weitere Methoden hinzufügen. Mit der komplexen Klassenhierarchy z.B. der Morphe muss man sich nicht herumschlagen.
- Bert -
Hallo Herr Freudenberg,
vielen Dank für Ihre aufschlussreichen Bemerkungen.
Von Ihnen hatte ich mir auch noch eine Antwort erhofft, warum man in Squeak 4.1 nicht von der Kachelversion eines Skripts zur Textversion übergehen kann. Markus Schlager vermutet, es ein "bug".
Viele Grüße
R. Baumann
On 20.07.2010, at 15:54, Rüdeger Baumann wrote:
Hallo Herr Freudenberg,
vielen Dank für Ihre aufschlussreichen Bemerkungen.
Von Ihnen hatte ich mir auch noch eine Antwort erhofft, warum man in Squeak 4.1 nicht von der Kachelversion eines Skripts zur Textversion übergehen kann. Markus Schlager vermutet, es ein "bug".
Stimmt.
- Bert -
wundere mich nur gerade, warum/ob meine mails nicht an die Liste gehen.
Markus
On Sun, 18 Jul 2010, R. Baumann wrote:
Ich selber habe früher auch daran gedacht, genau diesen Weg zu gehen: Kachel-Programmierung mit Etoys und dann durch die Falltüre 'Textversion des Skriptes' hinab in die Tiefen von Smalltalk.
Sehr gut - es ist der "Königsweg" Smalltalk!
Nein, finde ich nicht mehr so ganz. Es ist ganz in Ordnung, weil man einfach zeigen kann, was wirklich hinter dem ganzen steckt, weil ein Schüler sieht, daß das in der Programmiersprache auch nicht viel anders aussieht als bei den Kacheln. Richtig hilfreich wird es, wenn man mit Kopien und Geschwisterinstanzen arbeitet und die Schüler beim Programmieren dummerweise die Kachel einer falschen Instanz erwischen, sodaß dann im Quelltext statt 'self' plötzlich ein anderer Name steht. Ja, man kann damit manche Dinge ganz gut erklären und zeigen.
Aber wie geht es dann weiter? Man könnte die Schüler einzelne Etoys-Skripte in der Textansicht schreiben lassen. Aber warum sollten sie das tun, wo sie die Skripte doch zusammenklicken können? Worin bestünde aus deren Sicht der Mehrwert?
Wenn das Ziel 'objektorientierte Programmierung' heißt, stellt sich auch die Frage, wo diese Skripte denn eigentlich 'sind'. Und da landet man dann bei seltsam benannten Unterklassen 'PlayerXY' einer sehr komplexen Klasse 'Player'. Und ausgerechnet diese Klasse implementiert Prototypen, also nicht gerade typisch für Klassen.
Von der Modellierung her lernen die Schüler andererseits, daß der Königsweg zu neuen Funktionalitäten über Vererbung und Unterklassen führt.
Wenn ich zwischendurch Konzeptionelles mit den Kacheln zeigen will, kann ich ja auf das Etoys-Image zurückgreifen. Was ich da nie einfach geschafft habe, war, aus etwas mit Kacheln Programmiertem eine Unterklasse zu erzeugen.
Was heißt das? Wozu wird das benötigt?
Konkret, was ich einmal versucht habe:
Ziel: Massenpunkte im Schwerefeld. Plan: Nimm Etoys-Ellipsen aus dem Objektkatalog, erweitere sie um physikalische Attribute und Methoden (masse, geschw, beschl etc.) und packe das Ergebnis in eine neue Unterklasse.
Es gibt schließlich den Programmieren-Knauf im Halo (den mit dem Schraubenschlüssel). Und der bietet einen Menüeintrag 'Unterklasse anlegen'. Gelesen - getan. Und? Es entsteht eine Unterklasse des *Morphs*, deren Instanzen aber nicht einmal das aktuell gemalte Bild haben, sondern ein Standardsymbol (etwa die Zeichenpalette) zeigen. Die neue Klasse weiß als Unterklasse des Morphs natürlich auch nichts von meinen tollen neuen Attributen und Skripten. Pustekuchen.
(P.S. natürlich weiß ich mittlerweile, daß ich einen Massenpunkt als Unterklasse einer Ellipse eher schlecht modelliert habe, aber ich wollte an sich eine Unterklasse des Darstellers, nicht des Kostüms.)
Irgendwann steht so oder anders der Schritt an, Workspace und Browser einzuführen. Ich denke, ich würde das eher früh machen - ich denke hier freilich an die Zielgruppe Zehntkläßler, die in der siebten Klasse mit Scratch oder Etoys die Kachelprogrammiererei bereits einmal kennengelernt haben und Kontrollstrukturen wie Verzweigung oder Wiederholung bereits kennen.
Eine andere Frage ist dann auch noch die, wie man seine Werke eigentlich abspeichern will/soll. Da tendiere ich mittlerweile voll zu Monticello, sobald es ans Smalltalk-Programmieren geht, weil ich als Lehrer ja auch an die Werke meiner Schüler herankommen können möchte.
Bis ich dann irgendwann darauf gestoßen bin, wie trickreich die Klasse 'player' gemacht ist.
Was soll eigentlich die Theatermetaphorik (player, costume etc)? Wo kommt das her, wer hat das aufgebracht?
Die naive Vorstellung ist: Es gibt Objekte und Skripten; letztere dienen dazu, den Objekten vorzu"schreiben", was diese zu tun haben. Was sollen in diesem Zusammenhang "Spieler" und "Kostüme"?
Die Skripte sind so etwas wie die Regieanweisungen oder das Drehbuch, wobei ich eher sagen würde, die Skripte beschreiben, *wie* ein Darsteller etwas zu machen hat. Die Theatermetaphorik gibt es auch bei Scratch, wo die Welt sogar 'Bühne' heißt. Player und Morph/Bild bzw. Spieler und Kostüm bieten, finde ich, eine recht gute Veranschaulichung des Prinzips der Trennung von Modell und View. Mir sind sie mittlerweile recht sympathisch.
Etoys-Image, ggf. mit Alt-W oder Alt-, ein Weltmenü öffnen, unter Hilfe den Einstellungsmanager öffnen, dort nach 'friendly' suchen und etoysfriendly deaktivieren - und das Image speichern. Dann kommt man einfach an Browser, Workspace und Inspektoren. Bei Bedarf kann man auch die Standard-Entwicklerklappen installieren. Noch hat man dann ein Squeak3.x-Image (stimmt das, Bernd?).
Das scheint mir zu umständlich.
Finde ich eigentlich gar nicht einmal besonders umständlich. Zumal es auch genügt, wenn der Lehrer einmal ein so umgebautes Image zur Verfügung stellt. Wenn ich zuverlässig mit Kacheln arbeiten wollen würde, würde ich in jedem Fall diesen Weg gehen. Es ist das Image, bei dem ich mir am sichersten sein kann, daß die Kachelprogrammierung in allen Facetten funktioniert. Aber ich weiß ehrlich nicht, ob man die Kacheln überhaupt noch braucht, wenn man mit den Schülern Smalltalk programmieren will.
Aber davon habe mich ohnehin verabschiedet, weil das Programmieren der Morphe auch in Smalltalk nicht wirklich schwierig ist, wenn man die entscheidenden Nachrichten gefunden hat.
Aber die erst einmal finden, ist doch das Problem.
Richtig, aber das ist in erster Linie ein Problem der Dokumentation, nicht des Images. Das Finden wird freilich umso einfacher, je leerer ein Image ist. Squeak3.9 ist besonders voll, denke ich.
Markus
squeak-ev@lists.squeakfoundation.org
-
Bert Freudenberg -
Markus Schlager -
R. Baumann -
Rüdeger Baumann