Custom Block With a Primitive's Selector Can Replace Primitive in Script Pics

Advanced Topics
1

I discovered this bug using a much different method than the one shown here, but the result is the same:

  1. Create a custom block.
  2. Right click on the definition hat and select "selector..."
  3. Click the little arrow in the text box and select the primitive of your choice. My example uses "move _ steps".
  4. Make the definition of your custom block whatever you want. My example uses "turn 15 degrees".
  5. Take a script picture.
  6. untitled script pic
  7. Import the picture. As you can see, it has replaced the primitive you chose in step 3.

Now, this may not seem like a big problem, but for two things. Firstly, you can accidentally end up having this happen by duplicating a primitive block's definition, because duplicating duplicates the selector. Secondly, primitives aren't supposed to be able to be modified by script pics:

Original post from before I understood the bug

Disclaimer: This bug will not affect 99.99% of users, and requires all four of these steps to occur:
1) Edit a primitive block.
2) Duplicate it in the context menu.
3) Create a script picture of either block.
4) Actually want to be able to reimport the picture into Snap!

How to replicate:

Modify any primitive. I used the "go to" block. Select "duplicate block definition", and modify the duplicated block to help with identification later on. Also modify the primitive to have your own special definition:

untitled script pic (1)
untitled script pic (1)494×188 22 KB

Here are the two blocks:

untitled script pic
untitled script pic362×162 11.4 KB

I hope you can see why we need the second block - it is the only way to implement the first (unless you use another go to block, like the go to x,y block, but imagine for now that for this project we need to modify those too).

Try importing the script pic above! The custom block gets replaced with "Undefined!" and the primitive inherits all the modifications of the custom block. Saving the project does not cause any difficulties, however. Thanks!

PS: Why is this in Advanced Topics?

Screenshot 2025-02-23 155702 Solved by ego-lay_atman-bay in post #3
The only difference is that they're duplicating the original block, rather than manually creating the custom block.

2

Please don't post stuff like this under "bugs", because it's not, it's you not understanding the implications of some Snap! internal that there absolutely is no need for you to understand, but it conveys the wrong impression that there's something wrong with Snap! to actual educators whom this doesn't affect. Also, please stop obsessing over metaprogramming, dunno if I've mentioned this lately, but metaprogramming is for devs of libraries, and not so much for your regular projects. People in this forum obsess over features that aren't ever used in schools, and all this obsession is actively harming us.

Instead you could pose this as a question ("how are you dealing with this weird way of same-name-conflicts that no other programming language allows but that I somehow want to use in Snap!, hmmm?")

If you want to develop your own libraries you'll find ways to manage this exact problem, here's how I'm doing it in the Embroidery library:

primitives
primitives1096×1156 130 KB

3

But they're not dealing with same-name conflicts, they specifically said

And they clearly show 2 blocks, the modified primitive, and the custom block, which is a different name than the primitive.

Furthermore, what does this have to do with metaprogramming? They're editing the blocks manually, and they're also just using a custom block to house the original primitive function, exactly the same thing you do with the embroidery library. The only difference is that they're duplicating the original block, rather than manually creating the custom block.

They're just explaining how after duplicating the primitive block and editing the new custom block, the custom block will be replaced with an undefined block, and the primitive will be replaced with the modifications you did to the custom block. I was able to reproduce what they're doing without renaming the primitive.

I did also test to see if it was the selector of the duplicated block that was the issue, but it doesn't seem to be, which further emphasizes that this is not a same-name conflict.

4

Oh, wow, that works properly?! I guess this is a more niche bug than I realized. I can just create the helper block manually (rather than by duplicating) for the project I discovered this in, and no problemo! I guess this shouldn't be a very high priority for @jens to fix...

5

I mean, my schools have never used Snap! as a part of any programming programs functions classes curiculums, but I still use it, because why not?

6

I'm guessing that this is for the entire forum and its users, but I actually rarely use (let alone obsess over) metaprogramming. More recently I have been dealing with script's contexts and variable contexts, but that is about the extent of my use of metaprogramming features. For things like the define ((block)) [] (()@>), the only time I've ever used it is for my matrix algebra project, which allows you to create a block that will report a matrix of your chosen dimensions:

Matrix Algebra script pic
Matrix Algebra script pic482×272 30.9 KB

In any case, I would like to know what this "bug" (whether or not this is a bug I will not call into question here) has to do with metaprogramming. Thanks!

Believe me, I really don't care about understanding Snap!'s internals! I've seen quite a few topics on this forum in the past year that talk about those internals (e.g. optimization and nitpicking about your implementation of various features), which bugs me too (as someone who doesn't know a smidge of JavaScript and frankly doesn't care about Snap!'s source code)! This forum is for exercising the beauty and power of Snap!, not for going on about some JavaScript thing (contravertial opinion?). I'm guessing that these recent topics are what led you to respond this way.

Oh no! Is there anything I can do that'll help? I'll add a disclaimer to the original post to let people know right away that it won't affect them 99.99% of the time.

I just want to add that I love Snap! and think you have done a wonderful job developing and maintaining it. It is a fantastic tool that has ended up making me put off learning a more widely used, text-based language. I'd like to apologize on behalf of the forum for too often only pointing out what you can't do in Snap! or being ungrateful for new features and complaining because it doesn't go quite as far as we'd like (e.g. the variadic if before grouping of inputs was supported). Finally, I'd like to apologize for how many times I used brackets in this post (seven times, including this one) (this is a joke) (now we're at nine times).

7

I cannot agree more. Even though I know a bunch about snap's internals, and I have even contributed to snap twice, it still bugs me when people talk about all that stuff. In fact, what has discouraged me from posting, is all this talk about the internals.

I also agree with this so much. Programming is full of compromises. You cannot have everything done in the way you want, and if you do get it, you may also have to sacrifice other stuff that I'd say are more important. I especially hated the topic about a last key pressed reporter. I said, multiple times, the best way is to use a when [any} key pressed hat block, and store the key pressed in a global variable that you can use elsewhere, but noooo it's not a single reporter that doesn't require external setup and doesn't use a global variable. Guess what, the final block that did what the user wanted, is incredibly slow, since it has to check if a script exists in the current sprite, and if it doesn't, it created the script, and then I think it also used metaprogramming to use a reporter as a variable to store the last key pressed. My first solution is incredibly fast and efficient, and takes little to not effort to make, yet the OP just wanted an over complicated solution that used scisnap to create a script.

Why can't we just be grateful for the beauty of snap, and what we can do in it, rather than complain about how we don't have. I can't keep this in me anymore, I liked the forum a lot more in 2019-2020.

8

I think I have a theory. Maybe I don't, maybe I do...

When you go to to the snap! website you see this message

Snap! is a broadly inviting programming language for kids and adults that's also a platform for serious study of computer science.

and I think it should be edited to

Snap! is a broadly inviting programming language for kids and adults.

What I think, and I need to emphasise think is that a side effect of teachers teaching certain curriculums, and with certain goals is that they focus on a subset of those goals, and Jens, who is doing a lot of touring, hears a lot from teachers that try to follow those curriculums and meet roadblocks, so Jens works with them to implement.

The thing with teens, is they are intensely, intensely curious, and they see the next half of that splash screen as confirmation that kind of deep level thinking is encouraged and they get into trouble because while snap! is very powerful, it's not truly designed for computer science, it's as Jens said at his fossdem speech "Snap! is Scratch for college students"

Whereas Computer Science at it's core is a university level discussion and delving deep into those mechanics is part of the key teaching curriculum, cause the further you dig into Computer Science the more you're digging into the foundation of those building blocks.

My problem though, is at that level, text languages are still sacrament, whereas the big hurdle that snap creates, is that visual paradigm created by Scratch and Snap! establishes an idea that doesn't exist outside snap! or scratch yet.

Edgy kind of is that, because you can use it to build nodes and trees and visualise that data at a level that would be perfect for that kind of deep dive into computer science fundamentals.

Except it's written for Snap 4.2.2.9 and the "source code" link goes to the modern snap repository, so no-one knows how to do it. Well, I'm sure someone does... somewhere.

Now. Full disclosure, as an Australian, when I hear "college" I think Year 11 and 12, ie; the end of high-school, so, 17 year olds. Whereas college nearly everywhere else is the undergraduate step of higher education. So, after high-school but before university.

So there's a language gap here, but Snap! on it's terms of service specifies 12-20 but everyone is welcome regardless, but the teaching is absolutely written for that age range, whereas this forum is attracting the kids in that age range that want to jump well ahead of that because they're curious, and also adults with decades of experience in CS who like messing around in snap! because it's fun. Which is very true.

I think that's what the collision is. (Deleted word salad for later) LOL

9

:/

I completely agree with this theory

This is exactly what I thought when I first found Snap! in late 2021

10

I love snap, love it, but I want, and have wanted to extend and then rewrite snap for a long time. I have no intentions to replace snap, none, but I would like to build a compiler and a parser and everything in between, One of my goals is a University Level Block Language, or atleast something I can use to educate myself at the very least, and one of those goals is teaching myself assembly or even machine code. I... have opinions on this. OPINIONS

I have three textbooks on hand that break down how they work, one for logo, one for scheme and one for java.

Brian (BH on these very forums) wrote the Logo one, The Sussmans wrote the Scheme one (SICP), and the Java one is from the Dragon book, ie, the one they use to teach in universities and I can find plenty more online if I choose, but they all pick a language of choice, get lost in the weeds and make explanations that don't match their diagrams, and can't see the trees for all the forest in the way. (Brian's less so... but he wrote it thirty+ years ago)

The problem is... I can't read text code. I've said this many times, people seem to think code between languages is interoperable if you just know how to think about it... and the problem is, all programming languages have evolved from the idea that every other language and/or compiler is a sparkling polished pile of rubbish and that theirs is superior... (It's not, they're wrong)

Every. Single. Time. That I try to adapt something to Snap! I run into a limitation of Snap! (Snap is getting much better at this though, more and more the problem isn't snap! but ancient flaws of ancient languages) a mistake made by the textbook authors (All but one of them was published before multi-core processing took off, and even then, their take was basically "Someone else will write a good compiler for that later, don't worry about it now") (SIGH)

My problem, basically, is the bootstrap paradox. Ie; In order to write a compiler for your language, you need to write it in another language first. I'd happily write it all for snap! but I'd have to interpret the hieroglyphics that is every other text language. I can't.

I CAN NOT.

I want to solve this by implementing a text reader and a file system and then something like a meta-circular evaluator, all the way down to the tree to a linker... so I can make my own language.

Oh... Wait. Those are written in text languages that aren't snap and are aimed at a different style of code than snap...

Round and round I go, where I stop is the same square I start at. Every time.

Like, for real I kinda gave up a couple years ago, because I honestly have no idea how to bridge this gap, but every now and again I get and idea and fail, rinse repeat.

My most recent attempt involved me spending last week hand decompiling the Wolf3D code into text files... No... Seriously. I was hoping I could break them down into a text file with all the defines and all the if/elses and all the everything else and either blockify them or hand make the blocks my self I could import it into snap! so I can use it's stepping algorithm to study the code...

Wolf3D is 32 years old in three month and for as simple as it is, is still 27 Thousand lines of code... For a game that, quite simply, is a rendered spreadsheet... No... Seriously.

That's a lot of work, and that's not even going into the codebases of the other Carmack games that I have the source for, Doom 3 hit over half a million!!! and duck knows how many lines of code something like Horizon Forbidden West has! (Not a Carmack Shooter, also a recent release, so that source will never be made public lol) (I Grew up on the Carmack shooters. Quake 1 and 2 are in my top ten games of all time, so is Forbidden West (it's No. 1 tbqh)

I've wall of texted. AGAIN. Sigh

Sorry.

11

Just FYI, I don't have a problem with people trying to understand Snap!'s source code and messing around with it, but this forum isn't the place to do that. If one or two people are doing that on this forum, I guess that that is fine, but recently it has felt like: complain about the source code this, why did you implement this this way that, etcetera. Some of these topics have felt like they belong on github, and others don't belong anywhere.

Obviously I can't be the one to do this because I don't know a text language, but have you ever considered enlisting some help?

12

Alright, after a bit of research, I think I understand what is going on here. Firstly, customized primitives aren't supposed to be saved with script pics (something I'd forgotten, but I think it's a good thing):

The selector of the block is what identifies it when saving/loading if it has a selector. By looking at the XML, I discovered that this test:

probably didn't work. You see, for whatever reason (there is probably a good reason, I just don't know it), when setting the selector of the block to nothing, this change isn't saved. If you change the selector to something other than an empty text string, then trying to import a script pic of that block completely fails. Moreover, if you set the selector to an empty text string using metaprogramming, things behave as expected. The primitive definition is lost, but the custom block remains.

Therefore, when the script picture is saved, it has this custom block which has a selector that is the same as the primitive, and the primitive edits aren't included. When the image is imported, Snap! doesn't see the edited primitive, but it does see a custom block that looks like an edited primitive. The custom block is lost and the primitive is replaced, creating the effect described.

This leads to two things:

Firstly, I would propose that "duplicate block definition" should not duplicate the selector. As far as I know, the selector is not something that end users are supposed to be using anyways. This would fix this issue and make what is going on a whole lot more understandable.

Secondly, by using this bug, one can get around this:

Here's how:
Don't bother with the primitive other than duplicating the definition. The script pic won't save it anyway. Now that you've duplicated the definition, take this new block and make the modifications you want to have in the primitive. If you need a dependency, make that by hand (not by duplicating). Here is an example of this in action:

untitled script pic (1)
untitled script pic (1)364×276 16 KB

The first block is the primitive, the second is the custom block which houses the modification you want to the primitive, and the last is the dependency.
This is clearly a bug, especially because you (@jens) specifically designed script pics not to work this way. Even if you change the behaviour of "duplicate block definition", this still can be achieved by manually changing the selector. I would recommend patching this.

PS: I had also tried editing the selector to see if that helped, but got bitten by

so I didn't think that it could possibly be a same-name conflict:

But apparently it is, and you probably knew enough of what was going on to know this too. I'm sorry, but I really had tried to my wits' end to make sure that this wasn't a same-name-conflict.

13

Just FYI, I don't have a problem with people trying to understand Snap*!* 's source code and messing around with it, but this forum isn't the place to do that. If one or two people are doing that on this forum, I guess that that is fine, but recently it has felt like: complain about the source code this, why did you implement this this way that, etcetera. Some of these topics have felt like they belong on github, and others don't belong anywhere.

I agree, the thing is, I'm not after snap!'s source code. I've got Carmack's code and Farbrausch's Werkkzeug code to search through, I've always wanted to make my own games, but can't program well enough, no, all I want is to build libraries to help me do it, but nothing is written for snap it's all written for obsolete languages that have found their niche and don't want to leave it.

Obviously I can't be the one to do this because I don't know a text language, but have you ever considered enlisting some help?

Many times, but basically, the "help" boils down to "Why don't you do it this way" and the "this way" in question is how they did it, and how I've been trying to do it for nearly thirty years lol.

There's a reason I only lurk these forums and seldom comment, cause when I do comment... WALL OF MADWOMAN TEXT SIGH lol

14

Sorry, I guess I wasn't clear about my test.

I edited a primitive, duplicated it to a new custom block. In the new custom block, I set the selector to nothing, so there's no selector. I then created a script pic, opened a new snap instance, and when I imported the image, the primitive was replaced instead of creating a custom block. Oh, I also removed the <> primitive [ V] block from the definition, so that's not why it replaced the block.

15

That is what I tried, but

16

Oh right, I didn't bother to check that.

17

literally where

18

I guess that

wasn't very accurate. At the time of writing I had been rereading quite a few older posts, so, in reality, "recently" really meant over the past 6 months to a year. In terms of a real "recently" at the time of writing, there were two or three topics that bothered me:

  1. The topic about optimization. There were times when I felt like sarpnt was borderline complaining about/criticizing how Snap! handles certain things.
  2. There was a topic which literally asked how to do something in (morphic?) (JavaScript?). There was no explanation into what they were planning to do, just a question about some function.
  3. I feel like there was someone trying to mod Snap! and thus asking questions about the source code. I can't remember for certain.

Further in the past, there were another couple mod topics. There were also a couple of topics which I felt like were the

part of things. They were pretty innocuous, but it was just another straw on the camel's back. These were topics where users repeatedly mentioned a feature request without remembering to be gracious and recognize that the feature their request relates to is pretty new itself. An even bigger example of this, which took place even further in the past, was the whole "group inputs" dialogue/argument/fiasco.

Overall, I think I overstated the issue and was to some degree unfair (sorry), but my point still stands.

I remember that! I was the one that provided that final solution ;). But, I did so because I wanted to help them recognize that what they were asking for was unreasonable. I find that if you just flat out tell someone that something isn't possible, they try to find a way anyway. However, if you provide them with a sorta solution that is really bad and convoluted, then they can recognize that you know what you are talking about and there really is no way to truly do what they want. Because, as I recall, even after we told them it wasn't possible, they kept trying all sorts of different things.

19

Just got bitten by this again in a different scenario. I have a multiline pen block that I used in one project:
Types script pic
I made it by duplicating the primitive definition to make the label/input stuff easier, and now it replaces the primitive whenever I try to import this block into another project! Moreover, the actual script imported is just an undefined block, so I didn't even realize what was going on (I thought it was just failing arbitrarily).