Smalltalk › Frameworks & Tools › eToys Development

broken project: cannot open Viewer on object

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

4 messages Options

Markus Schlager-2

broken project: cannot open Viewer on object

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.

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 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.

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.

Markus
_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Kreiso.006.pr (127K) Download Attachment

Bert Freudenberg

Re: broken project: cannot open Viewer on object

On 2012-11-24, at 21:24, Markus Schlager <[hidden email]> 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 -

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Markus Schlager-2

Re: broken project: cannot open Viewer on object

Thank you, Bert. I'll try what you're proposing.

On Mon, 26 Nov 2012, Bert Freudenberg wrote:

> 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.

There weren't any textual scripts involved. The students are doing
tile-scripting only. Having variables and scripts with the same names is a
typical mistake among them.

Markus
_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Ricardo Moran

Re: broken project: cannot open Viewer on object

Hi, I've found a way of triggering a similar (maybe the same) error. The steps to reproduce are:

1. Create a new variable named "foo".

2. Create a new script named "foo" that assigns something to the variable.

3. Add a parameter to the script.

4. Create another script named "foo" (it will be automatically renamed to "foo1"). Make this script call the previous "foo" script.

5. Rename variable to "foo1".

6. Boom! :)

Now this is very strange, I don't know why, but after I recompiled ModifyVariableDialogMorph>>#doAccept (without making any changes to the code), the error just went away.

Cheers,

Richo

On Mon, Nov 26, 2012 at 4:21 PM, Markus Schlager <[hidden email]> wrote:

Thank you, Bert. I'll try what you're proposing.

On Mon, 26 Nov 2012, Bert Freudenberg wrote:

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.

There weren't any textual scripts involved. The students are doing tile-scripting only. Having variables and scripts with the same names is a typical mistake among them.

Markus
_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev