Blocks for programmatic script building

by request of @sathvikrias,

here’s the full list of my blocks for building scripts. these are relatively old, so don’t expect them to work perfectly or be efficient in any way. as always, feedback is appreciated!
https://snap.berkeley.edu/snap/snap.html#present:Username=mctx_studios&ProjectName=metaprogramming%20tools

really amazing. With a few changes, I would love to see all of these added to the metaprogramming library. As a result, basically all these changes are extremely minimal.
First, I would change the category color because pen and operators are already green.
Second, the replace block is a bit too long for my liking (again REALLY not important to change). I suggest this:


third, I would change the variadic input block into this:
metaprogramming tools script pic
and finally, I think you should add support for editing more than just the toplevel script (blocks inside a forever block).
I’m confused to why the split by blocks and fix is needed.

really great suggestions! i’m planning to do a full rewrite of the blocks, so i’ll keep these in mind!
the split by blocks and fix is the main component of these blocks, and it may not seem different at first, but it’s the subtlest change there could be.
normally, when inputting a single block into split ({} @>) by [[blocks] v], you get
metaprogramming tools script pic (2), and with an actual script, you get
metaprogramming tools script pic (3)
but the slight inconsistency between these was enough for me to make an entire block for it, which makes it so each block has its own columns in the table, instead of singular blocks returning everything as one single list.
metaprogramming tools script pic (4)
metaprogramming tools script pic (5)

personally, i see the pen category as a teal/aqua color :)

like this?

One suggestion I have is to make the split by blocks and fix block is make it handle variadic inputs in a consistent and much more usable format. Take this for example

You can’t tell where all the variadic inputs are and you can’t just plop the inputs into a copy of the block that doesn’t have them all expanded.

A while ago, I managed to solve this problem by using codification, which you could use, but it does leave side effects (it can’t restore the original codification).


(obviously it would report it in the normalized way instead of this flat list)

However, you could also get the xml of the block and parse that to get the variadic inputs, which would not leave any side effects, but it might be more difficult (I haven’t tried).

I’ll do it. I already did variadic → xml, so i can make a split block pretty easily the other way around.