Dynamically populating dropdown input slots

[cymplecy]

@tethrarxitet

Also I just noticed, why were the blocks changed?

I imagine to reduce space taken up in the category

[ego-lay_atman-bay]

I think it's more due to how similar they are. They listen to updates to inputs, be it clicking a menu or editing an input.

[sathvikrias]

yes, i just wasnt sure how to make the expand block set the slots of the custom block rather than the slots of the expand block itself.

[mark4sisb]

Hey! I was doing the same thing! Here is what I have got:

@ego-lay_atman-bay

As I am writing this, I think it would also be cool to set thiscaller to the custom block inside a dynamic input script. That way these scripts can interact with the block itself, plus it would make creating custom blocks for dynamic inputs easier and more dynamic (for example, a custom block made for syncing variadic input slots, so you can just drop in the block instead of creating the script every time someone wants to use it).

I was thinking the same thing! Unfortunately, you currently need to type in the input name for my block.
Edit:
Alternatively, you can input the block you are using this block in to have the menu work, and use defaults:

NOTE: Due to a Snap! oddity, the menu won't work properly if the definition of the block you are using it in is currently empty (remember to hit apply to update the block definition).

[sathvikrias]

@mark4sisb

I was thinking the same thing!

yeah, that was why i was having trouble recreating the block. Hopefully this is changed!

[jens]

I've just released a patch that also features a custom "expand ... to ... slots" block in the metaprogramming library:

You might have to flush your browser cache to see the updated library version.

[sathvikrias]

Thank you!

[jens]

I've recorded an introductory video about the new features in v10.2: https://youtu.be/2HcLdoT5_6U

[bh]

@jens

I’ve recorded an introductory video about the new features in v10.2:

Nice! I love the example block. Maybe you should add it to the Frequency Distribution Analysis library and consider renaming that library to Data.

So, you don’t have to set the input to Scripted? Is there ever a need to do that?

Also, in the main script you use INDEX OF to find the right column, but in the menu event script you use the name directly as the index. I found that a little confusing because you didn’t say “you don’t actually have to use INDEX OF; you can use the name itself as the index instead of a number.”

But I love how enthusiastic you are! :~)

[sathvikrias]

@bh

Is there ever a need to do that?

for menus?

[jens]

Thanks, Brian!

@bh

So, you don't have to set the input to Scripted? Is there ever a need to do that?

You don't have to manually set the input menu to "Scripted", right. Except, if you've already set it to some other options or to another built in menu. Then you have to first explicitly change it to Scripted, because otherwise you might accidentally lose whatever you've written into the options dialog merely by dragging a menu hat block into the block editor and accepting the change. Also, if you want to get rid of a menu - including a scripted one - you need to do it manually.

@bh

Also, in the main script you use INDEX OF to find the right column, but in the menu event script you use the name directly as the index. I found that a little confusing because you didn't say "you don't actually have to use INDEX OF; you can use the name itself as the index instead of a number."

Ah, but those two cases are actually very different, and - I think - you really have to use INDEX OF in the first case. The main script uses INDEX OF inside the ring that's the fun(c) arg of KEEP in order to reference a single element in a list that represents a single data base record. You can't directly use the column name in this case, because KEEP doesn't pass it into the predicate ring. That's why - I think - determing the index of the column is the only way here. The second case, OTOH, references the whole column to find out all unique entries in it. For this case we can directly use the column name, because Snap's built-in dictionary feature lets us use multi-column lists as key - value(s) structures. The interesting variant here is that associations in Snap! are not restricted to 2-item lists. That's the real kicker

[bh]

@jens

Ah, but those two cases are actually very different, and - I think - you really have to use INDEX OF in the first case.

Gotcha.

This really is quite an amazing programming language. All those grownups don’t know what they’re missing. :~)

[jens]

Yeah, I gotta say, I'm irrationally excited about our new idea to start treating custom blocks as though they are sprites, with multiple - even parallel - user interaction scripts inside their definitions. This is almost crazy, when you try wrapping your head around it, a new kind of block-based metaprogramming.

Also, your idea and insistence to evaluate all the block instance's inputs - not only the literal ones as I first planned - makes such nested ad-hoc scripts possible and seem all but effortless and magic. Of course, if any of the embedded reporters have any side effects (e.g. "a new clone of ...") those will happen, which I'm still worried about. But the "magical" benefits of using Snap-Processes on the IDE itself like this for now clearly outweigh their downsides.

[bh]

@jens

Of course, if any of the embedded reporters have any side effects (e.g. “a new clone of …”) those will happen, which I’m still worried about.

If if turns out to be a problem, you can always declare that it’s an error for a block called in that situation to have side effects. (But it might be asking too much for users to recognize the situation if they didn’t write the menu-using block themselves. We’ll see…)

[qw23]

I hate to be that person ... the novel blocks: are sui generis in that they can only be used within block definitions. Then why don't they even have a help text attached? (nor can they be edited, which may make sense BTW considering their nature) - How about adding a short help text merely referring to the Youtube video for now?

#hatenothate

Something different (about the video): would the Titanic example also work if there were a person with Name = "Name"? I mean the first row is a legend, but it's eventually searched as a data row.

[jens]

Hat blocks are as of now uneditable (not just the new one), and the other "set" block can be edited but bottoms out to a primitive.

Documentation would be nice, hence my video about it.

@qw23

would the Titanic example also work if there were a person with Name = "Name"? I mean the first row is a legend, but it's eventually searched as a data row.

yes, the example would work, because the key is the first item in the list, and the look-up value is the second one or all-but-first of the association.

[owlsss]

@jens

I’m irrationally excited

I think the excitement is pretty rational

[qw23]

@jens

Documentation would be nice, hence my video about it.

Yes, the video is helpful. But how will ordinary users find it? That’s why I have suggested to create a help text referring to the video.

@jens

@qw23

the Titanic example also work if there were a person with Name = “Name”? I mean the first row is a legend, but it’s eventually searched as a data row.

yes, the example would work, because the key is the first item in the list, and the look-up value is the second one or all-but-first of the association.

I don’t fully agree. E.g. in the beginning of the video the following script is used:

This is similar to:

[sathvikrias]

yeah, it should probably be changed to all but first of (titanic)

[ego-lay_atman-bay]

@qw23

how will ordinary users find it? That’s why I have suggested to create a help text referring to the video.

@bh has said that he is already working on a help screen.

@bh

it'll have a help screen before the release. Still having the final details of the design worked out, though.