Custom blocks

[Bernat Romagosa]

Add support for custom blocks (i.e. functions) to both IDE's. The VM already supports call/return.

What's needed is:

1. ability to define a procedure in the IDE

2. assign a chunk ID to each procedure and store its code on board

3. add call blocks to palette (and also return blocks with and w/o return values)

4. make compiler generate code for calls (call code uses the chunk ID of the called function)

5. detect when a procedure definition is edited and:

• stop all tasks (in case there is a call to the procedure in progress)

• store new code on board

[Bernat Romagosa]

I think I differ with point 3. IMO custom blocks should behave like in Snap!, where you can just execute them as regular blocks. Call and run blocks will only be necessary when we implement semi-closures (how do you call closures that don't capture their environment? just first class functions?).

[John Maloney]

Hi, Bernat.

Re: IMO custom blocks should behave like in Snap!, where you can just execute them as regular blocks.

Yes, I totally agree. When I wrote "add call blocks to palette" I just meant adding block prototypes for the blocks the user has defined to the palette, just like in Snap! and GP. I did not mean a block labeled "call <name of function>".

My notes may have been confusing because I was thinking about the implementation. The code generated by the compiler for a user-defined block is a bunch of pushes followed by a call instruction. The 24-bit data field of the call instruction contains the chunk ID of the user-defined function being called.

As you said, some sort of "run" or "eval" block will be needed when we add semi-closures later, but right now we just talking about basic user-defined reporter and command blocks.

We do need "return" and "return <value>" blocks in the palette so you can use them when defining a function.

By the way, I fixed the serial port overrun bug. That bug happened to be a stupid error where I had used an explicit constant (0x1FF) in one place and failed to changed it when I added a symbolic constant definition for the "buffer mask". Later, when I changed the buffer size, that constant didn't change and was the wrong mask for the new buffer size. Moral: When you "generalize" some code by adding a symbolic constant, make sure you update the code to use the symbolic constant in all the places it is used. :-)

Anyhow, "forever [say 'Hello!']" should now work without returning truncated or corrupted strings. Give it a try when you get a chance and confirm that it works for you...

-- John

[Bernat Romagosa]

Oh, I see! Sorry, I misunderstood :)

Great to hear the forever say bug was such an easy fix!

I just got the blue pill in my mail today. I'm busy with the Snap! Cloud now, but I'll see if I can test it later this week.

[John Maloney]

Done!

[Bernat Romagosa]