shiftclick/primitives palette?
No, it'll be in the regular File menu if there are overwritten primitives.
FFS
I was testing out something in a project I'm making, and something went wrong, which I expected, so I reloaded to load the save I made 30 seconds before
And now literally every set [ V] to [] block is now Undefined!
I never edited the definition, but it had turned input #2 in it to a code input since like save 5 (probably something I imported overwrote it)
I am lucky that most of my code for this project is in Snap Lisp notation and are (obviously) not affected (the above was just the block version of something in lisp notation) but this is seriously annoying, especially since it decided now, randomly, to do it
Side note: Can we just make the set var to inp block a multi-line input, please?
Edit: oh are you kidding me it affects the blocks too (of course it affects the blocks) nah now I just gotta load from a backup
So you did, in fact overwrite a primitive block definition, and then again changed it later. Folks, stop whining about your own incompetence when metaprogramming, because this is exactly what happens if you don't know what you're doing.
(post deleted by author)
What? I wasn't even doing anything metaprogramming related
I was literally making commands for a text-based os simulator I'm making, and I tested out the read file command, it errored and I couldn't fix it. I reloaded to my last save and they were undefined
idk if you did, but jens definitely has something against metaprogramming
poor baby functions
Geez, of course you were!!! You overloaded a primitive with a custom block, and then you were mixing it all together with LISP text code and stuff. You can do all of that, but then you're waaaaay over the fence in territory where you're no longer allowed to complain if stuff happens to you.
I didn't even know the primitive was changed! I never changed it, and I was literally about to make a topic this morning asking if that block had been changed to be a code input
and I certainly never changed it a second time.
well you must have done something to overload that primitive. Because if you just open Snap! that block certainly does not have a code type data input slot!
Like I said, I must've imported something that overwrote it (I imported a bunch of things early on to try and make a thing work, most of which are deleted due to not solving the issue)
but the last thing I've imported in days was the try/catch library, and I know I haven't edited any primitives recently.
But there's an underlying issue here, despite the xml having the correct block there, snap doesn't recognize it. Also, like I said, I haven't edited anything nor have I imported anything that could in days, so why is it doing it now?
By the way, I made the backup save before I did anything that could have possibly broken the current save
Even loading a backup made minutes before that has undefined blocks? Why?
I fixed my issue.
The custom definition for the set block was reverted, causing the undefined blocks. So, I made a new project, duplicated the set block's definition, made it a code input, exported the project, got the tag for it, spliced it into an exported copy of my main project, and imported it back into snap.
To clarify, this is because instead of <block s="doSetVariable"> it was <custom-block s="set %s to %code">, which is why it was undefined (because of the lack of that block definition). Saving would've overwritten those with <block s="errorObsolete" or something, which is why I couldn't have saved.
After doing some testing, I have figured out how to reproduce this issue. Just to be clear, these tests did not do anything with metaprogramming, and I have not even looked at the xml in any way.
I created a project with just a move (10) steps block in the scripting area, and inside a custom block. I saved the project without touching the definition of the primitive.
If I then close the tab, and open a new tab, I modify the definition of the move (10) steps block to have an any input (so it's visually easy to spot). After modifying the primitive, I loaded the project (in the same session). The primitive in the scripting area is the unmodified primitive, how it should be, but when I look in the custom block, it's using the modified primitive.
If I then save the project (in the same session) without modifying the custom block definition, I can then open the project in a new tab, and inside the custom block is an undefined block.
Here's my before and after projects.
The issue seems to just be modified primitives carrying over to newly loaded projects in custom blocks, even though the primitive is reverted in the palette. This has nothing to do with metaprogramming (though metaprogramming can trigger it).
Unshared :).
Also, one of the times I experienced this bug, it also affected blocks in the scripting area (not just in definitions). That was also one of the times when I am fairly certain I didn't modify a definition.
Edit: Maybe I did edit the definition. It was in my Matrix Algebra project (not shared) and the block was an addition block. I might have looked at its definition out of curiosity briefly... Well, in the meantime, I know not to modify a primitive unless absolutely neccesary, NOT just out of curiosity.
Sorry, it just had the wrong link. It's fixed now.
Or you can just remember to open a new tab every time you want to load a new project. No matter what, you won't run into this specific issue if you do that.
hm, how?
Awesome sleuthing!
Thank you, @ego-lay_atman-bay , now I've got a clue to investigate into...
okay, with @ego-lay_atman-bay's help I've tried to fix this in v10.4-rc3 today. If you get a chance, please give it a try and let me know of any issues you encounter. Thanks!