Snapinator development (Snap! programmers wanted)

do you mind adding support for [scratchblocks] <[] contains [] ? :: operators> [/scratchblocks] ?
(it's possible to be case in-sensitive without JS:

Yes, I plan to add all the blocks in the default categories in some way or another.

also, I would do the pitch effect like this:

and, (sorry if this is not helpful) we can use a boolean (only possible in :snap:) to check if something is a math operation:
[scratchblocks]
not ((math operation) - (same math operation))
[/scratchblocks]

will report true, and

[scratchblocks]
not (text thing)
[/scratchblocks]

will report false, so it just might be possible to make a scratch list reporter without JS.

yes that works, only with english. It doesn't work with other languages.

¿Porque no?

Oh wait you're talking about CONTAINS, not about <NOT (text)>. Sorry.

Interesting. Is this intended behavior? I'd expect

[scratchblocks]
<not ((0) - (0))>
[/scratchblocks]

and
[scratchblocks]
<not (join [0] )>
[/scratchblocks]

to return the same thing.

actually, the text "0" is true, and the number 0 is false.

right, but I put it in a [scratchblocks] <not <>> [/scratchblocks] block, so it is opposite.

I also found that, it takes longer for something to be reported if you use a math operation than if you use a string (could be opposite in other cases):

it looks like it takes longer for the number 0 to take longer, but the number one runs one more block than the string one.
if I do


it takes a bit longer than with the 0 + 0 one

it takes way longer. But if I do this (without cached inputs)

which is specifically a number, then when I do the same script with a string instead, I get

which is close to the number version, but it's a small millisecond difference, so there really is no need to use number over string (and with this test, you can see that it's really no difference between number or string, heck the > predicate just takes the unicode of the two values and compare those numbers. I figured that out while doing this)

btw, I'm pretty sure you had cached inputs on, so when you did your test, it wasn't very accurate. To turn off cached inputs, shift-click the options (gear icon)

I don't know what those are.

about the scratch list reporter...

Solution

untitled script pic(29)

you can use that in the definition instead of JS.

That doesn't work. You need
image
To see why, put your definition in another reporter block that doesn't report a boolean.

I made that picture before I knew about the limitation of the safely try block. thank you for pointing that out! edit: I can't edit that post I made for some reason