scratchfoundation / scratch-vm Goto Github PK

• - Repeat
• - Forever
• - Wait - addressed in PR, minus arguments
• - Stop
• - Broadcasts
• - Green flag (no-op)

This is something that I think we need to resolve eventually. Right now in Scratch, if you click a running stack, that stack stops. But what happens if it was running a long-running block, like "motor on for 5 secs"? In our current model, the motor would stay on, I think... Perhaps tapping a running stack shouldn't stop it, or we need to think about how to implement stopping it.

For the "timer" blocks.

• Starts counting when the VM is loaded.
• Resets when a green flag event happens.

Currently, args are patched in for our horizontal prototype implementation.

We need to run blockFunction with some recursive evaluation so that args are processed before being passed to the outer block.

Use Case

• Assemble a stack of multiple blocks
• Drag to trash
• Undo

• - Tapping a block toggles its stack
• - Tapping green flag/stop button affects threads
• - Running a block feeds back the stack and block highlight events

Currently, only one field/shadow block is present in the VM's representation. For example, create an addition block. The left field is shown in the tree; the right one is not there.

(e.g., "color touching color" across a thread boundary).

In Scratch 1.0/2.0, this is handled by ensuring that all operations that need to block all threads are actually performed synchronously. So, one way would be to make sure that the reporter doesn't give up the JS execution thread until it gets its answer (while loop?). The other way would be to have a flag on util.yield that specifically disables running other threads until that reporter returns.

vm.js:1361 Uncaught TypeError: Cannot read property 'next' of undefined

almost definitely related to my changes. And possibly how flyout blocks produce weird events.

Also, sometimes:
vm.js:1391 Uncaught TypeError: Cannot set property 'topLevel' of undefined

and stacks appears out of sync...

What happened :)

How should these be handled in the VM? Should they be done like Scratch 2.0 (where there's an imperative method like allHatsDo), more like Scratch extensions (asynchronous vs. synchronous), or some mix?

It would be great to have a mode of execution where things are stepped by a button in the VM playground. The button would essentially call stepThreads() with a tiny WORK_TIME, to proceed one block per thread every time the button is pushed.

In the long run, it would be good to have single-stepping mode a la Scratch 1.4

Start the first motor block, then a second. The first one never stops running.

Another possibly the same, possibly different problem: start two motor blocks in a forever. Then start a third motor block. Forever behaves strangely.

@thisandagain

If WebWorkers are available, it would be great to launch the VM in a worker thread instead of in the main thread. It would be good to do this as soon as possible, so we make sure our implementation isn't accidentally doing main-thread-only tasks, and so that we get the timing right across the two threads.

We can create a couple of stub blocks in scratch-blocks and start working on this right away, I think.

https://github.com/LLK/scratch-vm/pull/72/files#r66794061

Two reasons:

1. It's not that helpful yet until we have actual extensions implemented.
2. The worry about it being a performance killer.

In Scratch 2.0, there's a global interpreter flag that tracks whether a block has triggered a sprite's drawn representation to become out-of-date. E.g, a "move 10 steps" block would trigger redraw, but a "set var to 20" wouldn't. The value of this flag determines whether or not a loop yields at the end of a frame (if the interpreter isn't in turbo mode). We need an equivalent flag in scratch-vm, and we can also use something similar to determine whether we should call the renderer's draw method.

https://github.com/LLK/scratch-flash/blob/master/src/interpreter/Interpreter.as#L84

An example of a block that needs this is an "HTTP request" extension block.

How should it work?

Perhaps,

• Mark the thread as yielded, and don't pop the stack to make sure flow control waits on that block.
• Add a util.report function that the primitive can execute when it's ready.
• util.report somehow bubbles up its value into the caller's arguments object.
• Make sure each reporter is only called once per block execution.

Best to do this right away, as it's bending my mind a little bit with our current set-up.

Some of the drop-down values don't seem to match up:

• Yellow
• Orange
• Red
• White

To accelerate VM playing and develop, we'd like to create a "VM playground."

This will link to scratch-blocks and pre-load a bunch of blocks. Ideally I'd like to create a small tool to explore the AST, step execution and explore the internal state, etc.

Until we can implement the VM in a WebWorker, running as much computation as we are seems to be hanging the main UI thread...this is mostly visible when dragging blocks around. It won't make it as perfect as we can, but we could improve it slightly by making the blocks execute for less ms.

Probably because they're not represented in runtime.stacks

These are in index.js currently and have some duplicated code for flyout vs. workspace blocks. Ideally I'd like to refactor it and move it into the Blocks module.

Sort out tests and node support for ES6 to ensure that we can still run tests / run the vm headless.

• Green flag and stop buttons as a stub
• Tapping on blocks makes them run
• Blocks feedback with glowing stacks

• 1. Context menu needs messages (currently shows up empty).
• 2. Host from 0.0.0.0 instead of 127.0.0.1.
• 3. Add documentation about make serve.
• 4. Add a redirect from / to /playground by default
• 5. Add listeners for the flyout workspace. The underlying issue has been fixed in scratch-blocks, so this should be possible now.

Repeat blocks with values more than zero always run forever, the loopCounter never goes down:

My browser / operating system: Linux, Firefox 50.0, Flash 11.2 (release 202)

See: https://developer.mozilla.org/en-US/docs/Web/API/Performance/now

Should be polyfilled when not available.

We created this infrastructure quickly to try to support the WeDo prototype. I think it should support our thread timing needs, but we'd like to have a discussion about it before we start building on it too deeply, as it's a little bit messy.

This seems to happen mostly when you drag a reporter into a shadow block slot.

To reproduce:
-Create a "repeat" block.
-Create an addition block.
-Drag the addition block into the repeat block's shadow space.
-Delete the repeat.

The addition block is still present in the VM's representation.

What's this in row 68 of src/engine/sequencer?
activeThread.status === Thread.STATUS_RUNNING;

Need to figure out how to associate blocks with particular targets. As part of this, it would be good to create the "sprite manager" as per our plans, which will store the master copy of data pertaining to all sprites, including x/y position, current costume, etc., and pass this along to the renderer on every frame.

Check out this video:
https://www.dropbox.com/s/k9klrgmntbitr2d/stop.mov?dl=0

At the 3s mark, I hit the stop button. What's going on?

Some of these names are not like the other. Notably, the "thread stack" is a very different thing from the "block stack." This naming situation has led to awkward situations, like pushing the stack to the stack.

We couldn't immediately decide on what better name to use (original discussion: https://github.com/LLK/scratch-vm/pull/72/files#r66675817) - continuing the discussion here.

See discussion: #72 (comment)

Currently it basically crashes the entire VM until you stop it manually by clicking the button.

Scratch-blocks is very simple about what stacks are glowed - you just tell it which ones to do and it will do it. We need to build in some smart behavior to the VM for when you are moving around executing blocks, which stacks should be glowed. For example, if you start executing a stack, let the execution point go to the bottom of the stack, and then pull off the bottom, the bottom will still be executing, when the top half is the highlighted one :(

Scratch 2.0 has a bunch of bugs here also so it may be tricky to get right, but important, I think.

Inserting blocks into the middle of the stack doesn't seem to be working correctly. The right things are not being executed, and I suspect it is related to MOVE