The one I made below it's too slow to be used inside a MAP block to do a pixels_of_a_costume manipulation that has been discussed here.
Can anybody make it a fast (JS-script) block?
(Edit: The xxx+0 on the first three lines ensures that JS sees the inputs as numbers, not as strings of digits.)
Thank you, Brian!
Question. What are the special characters that you use instead of "fuzzy =" (they look like "$=-2" and I don't understand), and the single sign you use instead of "+-", shown below in a printscreen of your custom block (and how can I get them)?
Those are Unicode characters from the "math symbols" section.
Starting with the second one, ± is "plus-minus sign," U+00B1. I don't know how your computer handles non-ASCII Unicode; on my Mac I click on the icon with a Command (cloverleaf) inside a tiny window up on the menu bar and choose "show emoji and symbols." Then you just type the character's name in the search bar and when you find the one you want, double-click it.
The other one, ≅, is "approximately equal to," U+2245. But, at least in my font, for some reason that character is way too small. In title text you can make anything bigger by saying $foo-2.5 where "foo" is the text to grow and "2.5" is the size multiplier. (The "-" is a connecting hyphen, not a minus sign.)
See page 46 of the manual for more.
Thank you.
I took a shortcut and simply copy-pasted those from your reply's text itself 
EDIT: And checked out the manual page 46 where you explain how to resize characters. Tnx.
It has been quite a long time and maybe in the meantime something has changed in Snap! so that it doesn't work, (anymore), as only today I had time to try it and it doesn't work - I wonder why? I copied and double-checked the commas and semi-colons in the JS-script. Am I missing something?
you input is named tolerance in the JS-function block's parameter declaration, but tol inside the function's body. Dunno if that's what JS complains about...
Brian explained to me that he introduced tol (which is set to tolerance + 0) , because otherwise JS might see tolerance as string of digits instead of numbers. But still it doesn't work...
Right after the words "JavaScript Function," you have three orange blobs; should be plain text strings. It's the formal parameters of the JS function; the Snap! interface comes in the "with inputs" part of the CALL.
my rambling
Oh, I guess it was against my expectations to have the formal parameters (of the JS) in front of, as opposed to behind the function's body because in Snap! I see them mostly behind it. Is there a reason that they're in front in this particular block?
EDIT
I have to admit I also forgot to put the JS block inside a CALL block, which is kind of embarrassing, but you didn't notice this my omission of the CALL block, either, so I'm not the only one who needs glasses to see better. Hopefully I have learned the "you shouldn't use a JS block without a CALL block" lesson.
Well, unless you put the function in a variable or a list or something, to be used later.
The inputs go in front because that's what JS code looks like!
function(x, y, z) {return 3x+2y-z}
some more rambling
I wonder in which case you would want to put a JS block inside a variable, would it be in order to be able to call it again and again, each time with different parameters? Or something completely different?
Maybe for most users that are familiar with the order in Snap!, the order could still be "a function's body first, parameters follow it", in this block as well?
Yes, exactly. Although the usual thing is to wrap the JS function in a Snap! procedure that calls it.
The idea is that only people who are comfortable writing JS code will use this feature. And while writing JS code, this is the order they expect. The parentheses and braces in the title line of the block are the JS syntax for a procedure definition! So the order really isn't something we can change without losing that connection to JS.
This is how grown-ups think, however, kids were never afraid of doing things they don't know how to do, since this is how kids basically learn anything despite not knowing or, likelier, precisely because of not knowing. I think we, as adults, should encourage kids to try things they don't know yet how to do, and even more, should make this easier to try; that is why I think the JS block, too, should/could have its parameters behind the way other blocks do. The block can show one order to a user, and only internally reverse the order before it passes it to an actual JavaScript to run, I think. It would be a kind of custom block, I guess.
I think you're trying to have it both ways about kids: They're brave enough to experiment with JS Function (and I agree), but will boggle at things being in a different order.
The brave kid you're talking about will look at other people's JS code, in contexts other than Snap!, and so will recognize function (__) {__} as correct JS syntax. That will help them understand that they're expected to put formal parameters in the parentheses, even though what's inside is text slots rather than orange blobs.
Your hypothetical kid is more likely to have read JS code than to have seen a gray ring with formal parameters! Almost always, Snap! programs use implicit parameters (empty slots) in the rings.
Actually, now I think of it, I'm not sure I'm understanding your reasoning. Are you talking about explicit formal parameters in gray rings, or are you talking about actual argument expressions in the CALL and RUN blocks? Because the latter are already in correct JS order for a procedure call: proc(arg1, arg2, ...) and are in any case irrelevant to where to put formal parameters.
You are right. Explicit parameters in Snap! are not being (yet) used as often as implicit ones, so my hypothetical kid argument isn't as convincing as it would be if it was the other way round.
That said, I have corrected the JS block the way you showed me and it does (when tested on its own) work fine, however, when used inside (the MAP block) nothing happens, which is strange and I don't understand it. You can set the JS_block_on Boolean to true to test it in the following project Redirecting to Snap!
The problem (or at least the first one that jumps out at me) has nothing to do with your JS block, but with your use of MAP:
There are seven empty slots in the ringed expression, each of which will be filled with the same item from the PIXELS OF COSTUME block, namely, a pixel, which is a list of four numbers. In the first three slots, which are the list input to an ITEM OF block, you are correctly expecting a pixel, and are using ITEM to extract each of the color coordinates. I think what you're expecting is what you get for the seventh slot also, the ELSE part of the IF. But slots 4 to 6, in the LIST block, seem to be expecting numbers. Because a pixel is a list of four numbers, and LIST is given four inputs, you're hoping that the first three will be filled with the first three numbers of the pixel, rather than with the entire pixel. Instead you need to use ITEM OF in those slots.
Thank you for spending some of your precious time to think what might be the problem. I appreciate it.
It turns out the MAP takes 9 seconds to map all the pixels and it works fine. YAY!!! :- D
(So it works fine the way it is, no need to use ITEMS OF... I just have not been patient enough as using JS variant does not make it much faster, at best 1 second faster, i.e. taking 8 seconds).
Wow, I still don't see how it can work! But, if it does, that's great. :~)