The Unrolling Plugin

This plugin is new in beta 9. As usual you have to turn it on in the plugin manager. It injects a new menu item into the menu you get when you right click on the canvas:

Select that and you get an empty grey box:

It's just an element, you can drag that around if you like (and put code and data into it, should you want to). But right click on it and you can select "start recording".

This automatically turns on Logging (which might cause Field to slow down a bit) and the box starts keeping a transcript of everything that you are doing in Field.

For the example here I have three elements. I've executed a line in "some notes" by hand (in the editor using command-return); I've option-clicked on "runnable" and I've both option-clicked "processing elements" and executed a piece of text in it.

Sometime later, right click and choose what you want to do with this information:

Right now you've got two choices that only have minor differences between them — we'll be adding more now that all the mechanics are in place.

Choosing "stop recording and make new references in order" gets you:

What's going on here:

  • The newly created boxes contain references to the boxes that you ran (or ran bits of code from).
  • They get made, from left to right, in the order that you executing things on.
  • They are free standing elements themselves — you can option click on them or edit the code that's in them.

There are a number of rules that determine what gets made and when. Right now they are pretty straightforward:

Individual text fragments get copied

So if I selected and command-return'd a piece of text in "some notes" I get a new box with that text in it that says something like:

# created from element 'some notes'
_self.v3 = Vector3()

Option-clicked boxes get copied or referenced

If you option-click on a box in Field it's contents gets executed and it might even keep running. Such boxes, when recorded, either get copied or referenced by new boxes. What's the difference? A copy contains it's own copy of the source code that was option-clicked (just like a text fragment execution); a reference simply uses the delegation structure of Field to refer to the contents of the original box. If the original box get's its code changed then the referenced version automatically updates.

Depending on which option you choose from the "stop" menu, Field prefers references over copies. But Field will always copy boxes that you've edited after you've executed something — since if it made a reference in this case, the reference would already be out of date and not reflect what it was you actually executed

Recorded boxes a subelements of the things they record

One final rule, hinted at above: the boxes that the recorder creates are always "subelements" of the things that they record (take a look at SelfAndProperties if this doesn't make any sense). This means that the newly created elements delegate the looking up of _self to the original elements. This gives you lots of things for free — firstly, you don't need to worry about code in the boxes referring to things like _self.somethingorother — these references are still valid in the newly created elements. Secondly, because Field uses _self for all kinds of internal magic lot of things "just work" in the subelements — for example, elements that are "bridged to Processing" get recorded correctly.

Where next ?

The current state of the Unrolling Plugin is pretty preliminary — it works, but we have plans for it. In particular it ought to be able to expose and notate the global variable read and write tracking that the Logging palette maintains. It also could pay attention to the timing information — when things were started and stopped — to produce scripts that could be executed from left to right by a time slider.

As usual, we'd be happy to hear your ideas.