Huh. Today I Learned: students can edit the report block and change the primitive selector from doReport to fork and then get very cryptic error messages from otherwise innocuous blocks.
Is that controlled by a setting? This feels like the classic (setq nil t) in ye olden Lisps.
Huh. I could have sworn there was a setting for that, but it seems to be gone. (There is a “blocks all the way” checkbox if you shift-click the settings gear icon, but you can edit primitives regardless.)
But while looking for it, I discovered that the name of “zebra coloring” has changed to “Contrast blocks.” :~(
Yeah, it’s sad. I’ve still called it “zebra colouring” here on the forums since then because it is clearer to me what that means.
Were students distracted trying to break Snap! by triggering strange errors? Or was it a one-off situation?
I don’t think they did it on purpose. Maybe they were just poking around at random and did it by accident. I’ll ask them today if the recall doing it.
So it seems that one of the kids in the pair did it kind of on purpose. Basically poking around to see what happened and then forgot that he had done it or didn’t realize it could explain the mysterious error they were getting.
Which is good news to me: Snap didn’t spontaneously redefine the report block out from under them. And an important lesson about being careful with power tools.
i mean if you really want to break a project but in a subtle way you could have the report block set its value to a slightly different value, maybe using this caller to do stuff
im not sure if it would work that way but whatever