The Unrolling Plugin (beta 9)
Field comes with a "Logged Events" tab in tool palette that, when turned on, offers a deep view into the inner workings of your code (and Field's code). But it's been a little under-used until recently.
The "Unrolling" Plugin is our effort to expose the data that the Logged Events tab is capable of collecting. It's primary purpose is to let you record what it is you are doing — what elements you are executing and what little bits of text — and to recast that recording into various kinds of new elements. We've found this very useful recently. As we've been working on a large and complex artwork we've been building little "scenes"; often to show other people. These "demos" used to me rummaging through our working Field sheets trying to remember what pieces of code get executed in what order to get to the thing that we want to show. The Unrolling plugin tries to make it easy for you build a sequence of Field elements that, when executed, get you right back where you wanted to be, while simultaneously being flexible enough not to "fix" what it was you were working on.
Recording something
This plugin is new in beta 9 / the development repository. 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 
-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 -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.