[etoys-dev] broken project: cannot open Viewer on object

Bert Freudenberg bert at freudenbergs.de
Mon Nov 26 07:51:25 EST 2012


On 2012-11-24, at 21:24, Markus Schlager <m.slg at gmx.de> wrote:

> Hi all,
> 
> Maybe someone could look into this.
> 
> Obviously, my students (10th grade) are great in breaking etoys. This project has a big painted object named 'kreiso'. Whenever you try to open a viewer for this 'kreiso' you get an error that Player222 does not understand #getSchimmeln. 'schimmeln' is probably a user-defined variable of this object. The viewer does not open (same error about #getSchimmeln).
> 
> On the other hand there _is_ an open viewer for an object named 'kreiso' which apparently looks the same as the big kreiso. But when you choose 'reveal this object' from the viewers menu, it turns out, that this viewer is a viewer of the tab of a viewer of the big kreiso.

Yep. Just close that viewer.

> I'm not sure, what is really messed up with this project. The students were not able to tell me what they had done exactly. As far as I can see, obviously they started scripting an object 'kreiso' (the big one). But then they opened a viewer on the viewers tab-picture by mistake an scripted this one (it always has the same name as the real kreiso). Maybe they deleted at some point a variable 'schimmeln' they had created.


I think what happened is that at some point there was both a variable and a script with the same name, and Etoys got confused. E.g. you can still see a "stoppeSkript" script if you browse the Player222 class:

Player222 selectors
==> a Set(#stoppeSkript #aufladen #setKreisobeladen: #getKreisobeladen #ladeAuf: #skript1: #skript1)

But there is also a variable called "stoppeSkript", and variables named "stoppe", "kreisobeladen", and "schimmeln":

Player222 slotInfo
==>  an IdentityDictionary(#kreisobeladen->a SlotInformation precision: 1 ; type = Number #schimmeln->a SlotInformation precision: 0.1 ; type = Number #stoppe->a SlotInformation precision: 0.1 ; type = Number #stoppeSkript->a SlotInformation precision: 0.1 ; type = Number )

However, only accessors for "kreisobeladen" are in the class (set/get), and only that inst var actually exists:

Player222 instVarNames
==>  #('kreisobeladen')

While I have no idea how this happened, to clean it up just remove all entries except "kreisobeladen" from the slot information:



Then the viewer opens just fine.

> When I turn off etoyFriendly and open a browser on this Player222 I find a method 'skript1:' the browser cannot display. It raises an error: otherCollection must be the same size.

That's a second, but equally strange problem. They tried to add a parameter to the textual "skript1" script, which somehow got messed up. Perhaps there was an error and they just closed it and proceeded. But now the "skript1" is in the viewer twice - once with a parameter, and once without. You can drag out "skript1:" and press Cmd-L to restore the previous source, which has no parameter. If you try to drag out "skript1" from the viewer you actually get the viewer for "skript1:".

To clean this up I'd suggest deleting both "script1" and "script1:" from the player's scripts dict:

Player222 scripts
==> an IdentityDictionary(
#aufladen->A UniclassScript - selector: #aufladen scriptEditor: ScriptEditor for #aufladen player: Kreiso
#ladeAuf->A UniclassScript - selector: #ladeAuf scriptEditor: ScriptEditor for #ladeAuf player: Kreiso
#ladeAuf:->A UniclassScript - selector: #ladeAuf: scriptEditor: ScriptEditor for #ladeAuf: player: Kreiso
#skript1->A UniclassScript - selector: #skript1 scriptEditor: ScriptEditor for #skript1: player: Kreiso
#skript1:->A UniclassScript - selector: #skript1: scriptEditor: ScriptEditor for #skript1: player: Kreiso
#stoppeSkript->A UniclassScript - selector: #stoppeSkript scriptEditor: ScriptEditor for #stoppeSkript player: Kreiso
)



> 
> I tried 'World attemptCleanup' several times on this project. The first run resulted in 6 repairs made, the second one in 1 repair and from then on every time I get 2 repairs made.

In the Transcript window it shows it identified that problem:
 fix type 4, sel = skript1
 fix type 4, sel = skript1:
but obviously it couldn't. I think it did not anticipate the same script being in the scripts dictionary twice, it should have deleted one of the occurences. Maybe attach your project to a bug report that would improve the cleanup logic?

It would be interesting to know what exactly happened - seems to be an unfortunate mix of textual and tile scripts with and without arguments having the same name as some variables that were added / removed in a way to confuse the system.

- Bert -


-------------- n?chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.squeakland.org/pipermail/etoys-dev/attachments/20121126/1b7c5e5e/attachment-0001.html>
-------------- n?chster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : PastedGraphic-14.png
Dateityp    : image/png
Dateigröße  : 29178 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.squeakland.org/pipermail/etoys-dev/attachments/20121126/1b7c5e5e/attachment-0002.png>
-------------- n?chster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : PastedGraphic-16.png
Dateityp    : image/png
Dateigröße  : 29404 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.squeakland.org/pipermail/etoys-dev/attachments/20121126/1b7c5e5e/attachment-0003.png>


More information about the etoys-dev mailing list