i want to be able to stop, pause, and continue scripts, but:
the project shows every way i tried to do this, but it was very hard just to make stopping a script work, and i couldn't find any way to get the continuation of a script
i think sprites should at least be selectable in the stop block
This isn’t a feature request or anything, but I second this. It would be very helpful.
I 3rdn this. This is already possible with JS, and I could probably make a few non-js blocks to stop a script. Ill see what i can do
That's actually what a coroutine is...
an alternate solution would be to create some sort of "yield" block, which would be used by the task to give control back to the caller. i made a demo of this:
The STOP block doesn't need an input because you can
TELL (sprite) TO (STOP ALL SCRIPTS IN THIS SPRITE).
You can't ask to stop a particular script because scripts don't have handles.
@slate_technologies is right to mention coroutines because another approach to your problem, giving the scripts handles by collecting their continuations. Then you can stop a script by just removing it from the run list; it'll stop at its next yield point.
Speaking of which, @pumpkinhead above is right to say you need a YIELD block. This is all demoed on page 100 of the manual.
unless i can find a way to insert yields into only the locations they would happen normally, i can't use yields. i need to pause and get the continuation of an arbitrary script.
what i'm thinking of is something like this:
(this isn't a real block and i wouldn't expect it to be)
the idea would be to stop whatever a sprite might be doing so i can tell it to launch it again later
also, yes, the stop block doesn't actually need a sprite input, but (my [self v]) isn't neccecary either. i think it's reasonable to have a shorthand
It's slightly insane but clones can be used as a thread implementation (with sprite inherited variables as a shared state)
used this way
.
Not really. This does not work for me 
"this script" should be a valid context for "stop THIS SCRIPT".
So prevoius example can be
.
.
BTW:
.
shouldn't "this script" report the innermost ring.
It's slightly insane but clones can be used as a thread implementation (with sprite inherited variables as a shared state)
this is pretty much the core of the idea i have, i can start and stop processes and keep track of them, but i can't pause and resume them (i can't get the continuations without knowing and manipulating the script beforehand, or a MASSIVE analysis tool to place yields everywhere)
shouldn't "this script" report the innermost ring.
the way i see it "this script" is supposed to refer to the outermost block connected, and be local to them, like if at the top you took the continuation. inner rings are inheriting it, and i think that makes sense because you could just create a variable that the ring uses in it if you needed to refer to a ring inside itself.
in your case, it seems to make the most sense to just launch and return act if you want that behavior
Yeah, I think this came up in another thread.
I was thinking you can redefine all the loop blocks to call your YIELD after each iteration, and you can explicitly put YIELDs in the code of scripts that will run for a long time without looping (e.g., at recursive calls to a recursive procedure). No need to automate insertion of YIELDs in scripts.
What you're asking for is first class environments. That'll happen someday, but I don't think Jens thinks it's urgent. We need another design meeting to go through all these proposals systematically.
and how exactly could i detect "run for a long time without looping" on every script?
i also imagine it would get extremely slow the more complicated scripts that are put into it get, with all sorts of custom blocks and such
Nope
Dont try to solve the halting problem
the way i see it lambdas and sprites (which i usually just call objects) are already first class environments, just buggy and inconsistent. if telling a sprite to stop all scripts in sprite works, why is that not a first class environment? similarly lambdas have environments, it should be possible to do a similar operation on them, and i think it would logically be "stop all scripts in object", not "stop this script", because really the "stop this script" is a separate script running in the same object.
the only issue is that (iirc) currently STOP can only use the sprite that a script runs in, not what it runs ON.
i'm working on a project that i think gets across my object ideas pretty well, and i would be happy to elaborate on some of my ideas more
this isn't the halting problem, it doesn't need to detect if the script ever stops, only if it hits any point that could cause a repetition, snap already does this and does the yields internally, my issue is just that it would be extremely difficult to replicate that with a code scanner implemented in snap, and would likely be TERRIBLE for performance, which i just can't do for this
Right, but you don't have to do that. Just redefine all the loop blocks, the usual way, in a Block Editor, to put a YIELD block right before the repetition happens. By my count there are five primitive loop blocks: FOREVER, REPEAT, REPEAT UNTIL, FOR, and FOR EACH ITEM. And for blocks you write for your project, while you're writing them, you put in YIELDs yourself where they're needed. Figuring out good places to put YIELDs doesn't require you to solve the halting problem.
this doesn't work for the recursion issue you mentioned and redefining a block doesn't replace the original.
i don't think it would go well to try and get people to switch out all their loop blocks for ones that look exactly the same but are actually slightly different. again, this is for a library.
i'm also suspicious this would slow down code tremendously even if i were to do it
(for others, this project has some of my proposals, i posted it elsewhere when part of the conversation moved there)
You learn something every day! I wonder if that's good or bad.
