Obselete blocks

[stezel]

We are getting some Piazza issues from folks who cleared their cache after 4.1 release. Kindly see below:

Hi

• I wanted to ask about the following two issues....

First, I have a student who has obselete blocks within his project. Generally, my understanding of this kind of thing is that there's something missing - an entire custom block that he'd made.

http://snap.berkeley.edu/snapsource/snap.html#present:Username=jscherer&ProjectName=Polygon%20Project

I was wondering what might have triggered this?

Second, we are having a lot of issues with reporters not reporting. As we're early on it's not so much of an issue, but as we get closer to the Create Task, I get worried about this kind of thing becoming a big problem. Sometimes we can have them save and reopen and it works. And that's not such a problem. Other times they need to rebuild the entire custom block they've made. It's not such a big deal when it's a lab to rebuild an entire block but it is a big deal when we're on a timed exercise. Are there updates/revisions going on that would account for this?

Thanks for any insights!

Hi. I also had a student with the "obsolete block" problem. It only occurred for that one student on one lab. The lab worked fine until she shared it. As soon as it was shared, the 'obsolete block" occurred. I never solved the problem. I was able to see her program running on her computer BEFORE she shared it.

Selim Tezel -Can you please kindly confirm that she had cleared the cache following the 4.1 update?

camille burke -Yes. That was the first thing I checked. She is using Chrome.

[jmoenig]

Hi Selim, I was answering that piazza issue just as you were, so my answer got rejected :-)

Looking at the project with the "obsolete" blocks I was able to see that these are already in the serialized project xml. This means that the project has been saved after the "obsolete" blocks first showed up. Unfortunately this also makes it impossible for me to investigate where and how the issue evolved in the first place. Usually "obsolete" blocks occur when users are editing custom blocks and leave the block editor open while switching to another sprite, and then drag sprite-only bocks from that other sprite into the still open block editor. Often it seems that users are specifically using this "trick" to access blocks that they can't seem to otherwise get (because they're local to another sprite).

The other other (reporters not reporting) is something I'd like to look into, it would help if I could look at an actual project that exhibits this issue.

[stezel]

Hi Jens, Sorry about having your response rejected. I did not know instructor responses were mutually exclusive. Camille Burke sent this link which may be of help to you.

Here is a link to the shared program with the obsolete blocks: http://snap.berkeley.edu/snapsource/snap.html#present:Username=stacyfortes&ProjectName=U2L3-WordPuzzleSolver

Thank you for your help and time, Selim

From: Jens Mönig notifications@github.com Reply-To: jmoenig/Snap--Build-Your-Own-Blocks reply@reply.github.com Date: Tuesday, November 14, 2017 at 12:18 PM To: jmoenig/Snap--Build-Your-Own-Blocks Snap--Build-Your-Own-Blocks@noreply.github.com Cc: "Tezel, Selim" STezel@edc.org, Author author@noreply.github.com Subject: Re: [jmoenig/Snap--Build-Your-Own-Blocks] Obselete blocks (#1933)

Hi Selim, I was answering that piazza issue just as you were, so my answer got rejected :-)

Looking at the project with the "obsolete" blocks I was able to see that these are already in the serialized project xml. This means that the project has been saved after the "obsolete" blocks first showed up. Unfortunately this also makes it impossible for me to investigate where how the issue evolved in the first place. Usually "obsolete" blocks occur when users are editing custom blocks and leave the block editor open" while switching to another sprite, and then drag sprite-only bocks from that other sprite" into the still open block editor. Often it seems that users are specifically using this "trick" to access blocks that they can't seem to otherwise get (because they're local to another sprite).

The other other (reporters not reporting) is something I'd like to look into, it would help if I could look at an actual project that exhibits this issue.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/jmoenig/Snap--Build-Your-Own-Blocks/issues/1933#issuecomment-344331455, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AUPWrQz8mNyIcjgRzjPi__ucXC4Y3I24ks5s2ctzgaJpZM4QdrDY.

[jmoenig]

Hi Selim, thanks for the link to project that lets me analyze the "obsolete blocks". Here's what I've found out so far: the type declarations for the inputs of the does __ have __ letters? have somehow been swapped. instead of "text-number" the input types of the custom block definition have been at some point reversed to "number-text", and since these input declarations are part of the block's fingerprint the block instances in the scripting pane can no longer find it and thus become marked as "obsolete". I am very surprised by this finding. It's hard to imagine what might have caused this other than somebody using a text editor on some XML file (a library or the actual project-stub). Do you have any idea?

[stezel]

Hi Jens, Alas, this is beyond my reckoning. With your permission, I will post your reply to the Piazza thread. May be a teacher may be able to tell. I am also cc’ing Mary as she is the creator of the word puzzle project and may have a sense for what might be going on. And here is the original Piazza post for Mary: https://piazza.com/class/h8yx482idav52y?cid=1757 Hope otherwise all is well, thank you again for looking into this. Selim

From: Jens Mönig notifications@github.com Reply-To: jmoenig/Snap--Build-Your-Own-Blocks reply@reply.github.com Date: Wednesday, November 15, 2017 at 2:09 AM To: jmoenig/Snap--Build-Your-Own-Blocks Snap--Build-Your-Own-Blocks@noreply.github.com Cc: "Tezel, Selim" STezel@edc.org, Author author@noreply.github.com Subject: Re: [jmoenig/Snap--Build-Your-Own-Blocks] Obselete blocks (#1933)

Hi Selim, thanks for the link to project that lets me analyze the "obsolete blocks". Here's what I've found out so far: the type declarations for the inputs of the does have letters? have somehow been swapped. instead of "text-number" the input types of the custom block definition have been at some point reversed to "number-text", and since these input declarations are part of the block's fingerprint the block instances in the scripting pane can no longer find it and thus become marked as "obsolete". I am very surprised by this finding. It's hard to imagine what might have caused this other than somebody using a text editor on some XML file (a library or the actual project-stub). Do you have any idea?

[maryfries]

What if they changed the input types in snap but the change just didn't proliferate properly? They have an obsolete command in there too; what if they mistakenly built the does have letters? block as a command, had two blocks with the same name, and the type change just didn't go through correctly? I've run into some weird hiccups with multiple blocks with the same name in the past... #1372

[maryfries]

Further thoughts. I think these are two totally separate issues:

1. Lisa's kid copied local blocks into another sprite as Jens suggested. It doesn't have to be as complex as how Jens suggested though. You can just drag the local block onto another sprite; it will show up fine there and it will remain appearing fine when you save it too. (It's not fine if you run it, but who actually runs their projects before sending them to their teacher anyway?) ;) It's only when you reopen the project that the obsolete block appears. There is no indication to the user (who doesn't test) that there is any kind of problem with their code until after it's too late to debug the problem. And even if you do test the project, you get messages like this, which isn't super helpful even if you do happen to see hiding out by the sprite icons for just a few seconds before disappearing: Can we show an alert the second someone drags a local block into another sprite? Or can we prohibit copying local blocks to other sprites altogether? Or at a minimum, can we make the error message more clear and persistent?

2. Camille's kid's issue looks different, and I, like Jens, don't entirely understand it. (See my previous comment.) I asked Camille for more info on Piazza.

[jmoenig]

whoa, that's clearly a bug, @maryfries ! Just copying a sprite-only block to another sprite should either not work at all or make sure the definition is copied as well. I'll fix this. Thanks!

[jguille2]

Ok @jmoenig, only a comment...

If you want to fix this issue (that it is a certainly known behavior), I think the answer is to prevent copying blocks in a context where these blocks are not defined (we can not copy its definition... because maybe it does not make sense).

This issue is not only affecting to custom blocks. It is affecting also to stage-sprites blocks. For example, if I copy [move %n steps] from a sprite to the stage, the block is copied... but it does not work!

[jmoenig]

yes, @jguille2, you're absolutely right. In fact, I'm somewhat surprised that this isn't already the standard behavior, I'm quite sure that's how I implemented it at one time. Oh well, some things must have overridden this at one point. But I agree, I would make sure not to copy any sprite-local block instances among different sprites, unless the target sprite has a corresponding definition for that block.

[jguille2]

Ok, And I guess that what we copy only the call. And polymorphism can cause each call to act differently, according to its definition (wich must exist, of course)

[jmoenig]

this used to work right until 4.1 - I must have changed the copying mechanism for methods and simply forgotten a detail....

[brianharvey]

I'm sorry for being infinitely behind on email, but I'm a little confused about this. If you clone a sprite that has local blocks, or even duplicate a sprite that has local blocks, the new sprite gets a local block that works, right? So imho that's also what should happen when you explicitly copy a local block into a different sprite.

I feel this is especially important when the issue is about Motion primitives, which from a user's perspective are global even if they actually have an implicit reference to a particular sprite built in.

[jmoenig]

Naw, don't worry, everything should now work exactly as you'd expect it to. If the target sprite understands the local block, it gets copied. "Understanding" means it knows a method for it, which it either has itself or inherits from a parent. Global blocks aren't the issue here.

[jguille2]

Thanks @jmoenig I've tested this into 4.1.0.5 and it's Ok (about copying custom local blocks)... so this issue is well closed.

I just want to point again that a similar problem still exists with global blocks because the stage-sprite differentiation. Then, after copying, on stage we have: Maybe we can open a new issue? We don't need a quick solution... because this behavior is not new, and it is more about the OO in the main level (what is global? which is the sprite prototype?...) and this is a very important question. Now we have different relations: stage-sprites, parent-child sprites, anchor-parts sprites and clones! I love these features... but we must take care about the way to show these coherent and robust ideas. Joan