Concurrency in Blockly (and UI.Flow)

[Øyvind Teig]

I am new to Blockly and this group. And to UI.Flow (UIFlow) used in M5Stack. Many beginner's matters here, I would think. I am out after understanding where concurrency stands for Blockly and things built on it. For a blog note to start with [0], then for selecting which HW platfrom to play with next.

I found in that concurrency is (was?) not supported in Blocky. And instead that (Andrew Stratton) “If you want to teach concurrency/parallelism – then again, I would go for a Go specific set of blocks – which could nicely allow for go routine, wait groups, channels, etc.” [1]

In UIFlow (M5) there is the infinite loop, but I have not found anything about multiple communication loops / concurrency. I assume that UIFlow is based on Blockly? If multiple loops were possible, there would have to be communication like one might (not really) see in Scratch [3]. And that there might be some kind of (logical) multiple choice (select) in there?

Are Blockly (Google) and Scratch (MIT) related in any way?

Could anybody get me straightened out on these points?

[0] My embedded RTOS notes - Disclaimer: no money, ads, gifts etc. on any of my blog notes. Only fun and expenses!

[1] Go generator (Mar2017)

[2] Loop in UI.Flow (as in M5)

[3]  Sending and waiting for messages in Scratch (its runtime)

[Coda Highland]

The relationship between Scratch and Blockly is somewhat indirect. The new, unreleased version of Scratch is being built on top of Blockly, but there's no formal relationship between Blockly and the release version of Scratch except for inspiration.

True concurrency isn't supported in Blockly per se. The Javascript execution model is almost exclusively single-threaded. However, nothing stops you as the embedder from using Blockly to generate code (in whatever language you find appropriate) that can be invoked concurrently by another process. This is where Andrew Stratton's suggestion comes into play -- since Blockly is designed to generate code in other languages, you can have it generate code in Go that includes whatever structures you find appropriate.

That said, there is a way to simulate concurrency in Blocky. Check out the documentation on parallel execution: https://developers.google.com/blockly/guides/create-custom-blocks/block-paradigms#parallel_program -- this isn't true concurrency, as only one instruction is ever executing at a time, but there can be multiple threads in a cooperative-multitasking sense.

/s/ Adam

--
You received this message because you are subscribed to the Google Groups "Blockly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blockly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/0d92d274-fafc-44dd-a59b-1c1b497cb1f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Øyvind Teig]

Thanks, Adam!

I was thinking about concurrency as threads and not parallel, and parallel as running on multi-core, one per core. 

You are really triggering my interest. This is completely new to me, to see a framework that might generate code and implement different paradigms in different languages.

I assume then that nobody has tried to use Blockly to make a graphical language that would implement Go's concurrency features? Did I get the general idea there? I guess such an implementation would be "graphical Go" by means of Blockly - because it would generate Go. Or.. graphical occam in the world I used to live in for years. Or graphical embedded C with task scheduler and task model and communication patterns.

How would one go about to define how the graphical symbols should look like? I mean, where are they defined? I see the parallel_program you refer to is code by text. Is this the underlying language in text, and not the graphics. I guess so. Where would, so to say, the graphics come in?

I did study (and then blogegd about) concurrency in JavaScript some years ago, and I came to the same conclusion:JavaScript tree becoming concurrent?

Øyvind

To unsubscribe from this group and stop receiving emails from it, send an email to blo...@googlegroups.com.

[Coda Highland]

I wouldn't make that assumption at all. Blockly is a scripting language, and like any scripting language its true power comes from what you can integrate it into. Who knows what people have built with it? I've heard of it being used as a way to express filter chains. Blockly itself isn't even involved in the actual runtime execution at that point, and those filter chains are doing realtime processing of audio streams or network packets. In my own project (a game engine), I use Blockly in an event-driven context so that multiple objects can interact with each other; it's not concurrent execution but it IS cooperative multitasking, and theoretically I could get away with running some of those event handlers on different threads (I just don't intend to bother, because it wouldn't gain me anything).

But you're right that at that point it would be 'graphical Go by means of Blockly". Or graphical Python, or graphical C... Blockly on Arduinos is pretty popular!

For the graphical side of things... well, it would probably end up looking like a representation of the textual code. Blockly already allows you to define functions. You could, for example, use a promise-like architecture; define a block that accepts an expression (which could be a function call) and returns a promise, and that block would execute its parameter on a thread and resolve the promise when it finishes. That would provide a basic concurrency primitive, and you could have a block that waits on a set of promises to resolve as a way to pick up the result, or you could use an event-driven architecture where the process triggers a callback when it finishes.

There are a ton of possibilities, and those are just the ones I could come up with off the top of my head.

Now, don't get me wrong, this is no small amount of work. One thing Blockly doesn't have is a concept of local variables (or even of compound data structures aside from lists), so you're going to have to do something to deal with that. And it's up to you to provide whatever shared-data and synchronization tools that you're going to need. But it is entirely POSSIBLE, and it'd probably be a lot of fun to work on.

/s/ Adam

To unsubscribe from this group and stop receiving emails from it, send an email to blockly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/812b9d86-0d67-4a2f-98ac-175b4302ddd1%40googlegroups.com.

[Øyvind Teig]

Thanks a lot for spending time on explaining things to me, Adam! I will push it on the top of my head when doing further reading.

[Erik Pasternak]

Just a couple clarifications, otherwise Adam's advice covers everything I can think of.

• Scratch 3.0, which launched in January, uses a fork of Blockly for the block editor. We worked pretty closely with the Scratch team on building it and all the code is on GitHub under their LLK organization. Their VM/runtime is pretty unique, though. Instead of generating text code they keep an AST in sync with the blocks and execute it directly. They mean it literally when they say the blocks are the code. =)
• Blockly isn't itself a language. It's a tool for making block languages. ;)

[Coda Highland]

Oh shoot, I missed the launch! Thanks for the heads up. I'm going to show my son.

/s/ Adam

To unsubscribe from this group and stop receiving emails from it, send an email to blockly+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/4ef0ffc7-1764-40fe-b3ce-f19f726cc18b%40googlegroups.com.

[Øyvind Teig]

mandag 8. juli 2019 20.35.42 UTC+2 skrev Erik Pasternak følgende:

Just a couple clarifications, otherwise Adam's advice covers everything I can think of.

• Scratch 3.0, which launched in January, ...(quote delimited by me)... Their VM/runtime is pretty unique, though. Instead of generating text code they keep an AST in sync with the blocks and execute it directly. They mean it literally when they say the blocks are the code. =)

It would be very interesting to see this elaborated or to get a url with some explanation. 

I did ask about the runtime etc. this winter, on the Scratch discussion board: Sending and waiting for messages in Scratch (its runtime) and it now seems like the info obtained there needs a fill-up.

Aside: bear in mind that I am not a compiler person and only know abstract syntax trees by their name. But I have written more than two runtimes that run out there in safety-critical systems, all for CSP-type acrhitectures (like Go does: Why build concurrency on the ideas of CSP?).

[Erik Pasternak]

I can give a rough overview, but for details you'd need to talk to the Scratch team.

The VM is in the scratch-vm repo, though you generally want to start with the scratch-gui repo which has instructions for building Scratch 3.0.

The VM itself keeps track of each stack of blocks as a separate 'thread.' When executing, it cycles through all active stacks (a stack is active if it was started by a trigger or a user click and hasn't executed to the end). For each active stack, it calls an execute method for each block in the next chunk of blocks with some rules for deciding how much to run. For example, a single iteration of a loop will generally run as a single step unless it has blocks that take time, like glide.

So it's using the same approach as Adam described, but each block has a callback for executing that block rather than interpreting text code.

Cheers,

Erik

[Øyvind Teig]

Thanks, Erik!

So there should not be that much magic in there. It's based on node.js which is very nice. (But I the other day somebody said they did not use generators/yield in there? I must have misunderstood). You earlier stated that:

mandag 8. juli 2019 20.35.42 UTC+2 skrev Erik Pasternak følgende:

..Their VM/runtime is pretty unique, though. Instead of generating text code they keep an AST in sync with the blocks and 

execute it directly. They mean it literally when they say the blocks are the code. =)

But would it use the AST to supply information, not for the scheduling, but for which calls to run once scheduled?

 
tirsdag 9. juli 2019 18.45.07 UTC+2 skrev Erik Pasternak følgende:

...For each active stack, it calls an execute method for each block in the next chunk of blocks with some rules for deciding how much to run. For example, a single iteration of a loop will generally run as a single step unless it has blocks that take time, like glide.

Is the above an example where the compiler would use the AST to insert the approprate code to run in each case?  

But then "the blocks are the code" would mean that there is no extra info in there to generate the code? 

[Erik Pasternak]

For Scratch there is no generated code. Each block has a method associated with it that runs when it's that Block's turn to execute. For example, here are all the methods that run for the various motion blocks. When the VM wants to execute a block it calls the corresponding method with the current values. This means you can do things like change the distance to move inside a loop and execution will immediately start using that value since there's no generation or compile step, it just executes on the current state of the blocks (with any variables in the VM like sprite position).

[Øyvind Teig]

Thanks, again! This is so nice! I'm closing now. Bye