Hello! I want to begin by saying that if you've been stressed lately, please enjoy the rest of your day! Anyway...
I was testing features in my custom types project, and everything went well. When I returned to the project after closing it, it stopped working correctly. Because I had a similar issue before (with the embroidery library), I reset the block palette, which didn't fix anything. Then, I went on a search for the position of the error, and I found that the index of primitive was the problem (the one at the bottom of the script).
Instead of returning the index (or even 0), it stopped the project. I even checked the inputs, and the identifier was part of the logic of tag list. Within that same script, I also checked whether logic of tag contained identifier, and it reported true.
Could I please have help understanding what went wrong? Thank you in advance!
Could you please share a version of this project (or post a script pic from it here) in which there's a script in the scripting area with the inputs that give rise to the error?
I don't think anything's changed about INDEX OF recently, so I don't see why saving and reloading should affect this code. But I don't know where to begin looking without an example.
That's the problem. It worked before, but now it can't use index of to delete the items. Maybe it would be better if you had access to the whole project.
It got worse. Many of the list-related blocks are no longer working in some situations, and the OK buttons of the editor windows do not close those windows. I tried replacing index of with a custom definition, and it somewhat worked, but now it’s not. I don’t know what happened.
(If you’re wondering, I determine whether a block works if say makes the sprite say “Hello” after calling the other block.)
No problem, thanks for reporting the GUI issues you encountered when attempting to work on the project. Snap! should handle circularity gracefully both in scripts and in the GUI.
Of course some primitives will run into bottom-less recursion and trigger an error, but that's to be expected. What should not happen is that dialogs become unresponsive. I've added some more guards against circularity issues in the UI to my current dev version for v3.4. With these in place you probably would've been able to fix these issues yourself. Feel free to try it!
Yes, I believe so. When I had this issue, the main thing I was testing was clearing the Global Type Tag (stored in variable __(TYOT)_Global_Type_Tag__. Unlike the Palette Type Tag, it was not circular, and my issue occurred during the item removal process. I know that I detected whether the tag input of my clear tag block was identical to the Palette Type Tag to protect against the deletion of data in that tag. (The Palette Type Tag is supposed to contain all of the types that have blocks associated with them.) Still, I don’t know how my script broke if I was getting the index of an item in Global Type Tag.
nope, I didn't change anything about index of, that's exactly what's to be expected when working with circular data, because Snap! tests for structural equality:
Therefore getting a stack overflow error message is fine.
What wasn't right was that trying to overwrite or delete a custom definition also caused a stack overflow, albeit a hidden one, which left the block editor unresponsive. That was caused by scanning the memory (all variables) for captured closures with instances of the changed / deleted custom block in them, and then running in circles. That's what I've changed.
But - that case also highlights one of the subtle problems in trying to make a programming language friendly. Snap persists data - the state of variables - in the saved project, and this state also includes procedures ("rings") and their captured environments ("closures"). When a programmer edits and changes a custom block, all its instances need to be found and updated, because otherwise the next time the project is opened, they will be orphaned from their definition, which some folks here falsely call "corrupted". Therefore scanning memory needs to keep track of items which have already been visited before. That's the part that had a circularity-guard bug in it. (But there are many other ways in which custom blocks can be orphaned, especially through metaprogramming, which should be totally obvious, duh!).
Traditional programming languages don't have this issue, because they don't save program state in their sources, let alone procedures and closures. Of course, the rationale behind persisting data in the project was so educators can bundle data and code for lessons like "Vee", and not for pranksters to outsmart the evaluator and complain about it here.That's what makes me "sigh"...
I'm confused, the dev version days 10.4, the current version is after 10.3.4 (10.3.6); is there something other feature that makes it like that? or do I not understand the versioning.
