New Block: ( index of ( txt ) in ( txt ) )

[averagewolfie]

I should note that I have successfully coded this block in a fork of three Scratch repositories, but I will keep the issue open until actual implementation can occur.

Expected Behavior

The block would be a reporter which takes a letter or phrase in a string, and returns the position of its first identified instance. If I were to say ( index of ( o ) in ( Hello world! ) ) then it would return 5, because it is the fifth letter in the string. (Technically it should be 4 but the way the Scratch interface is set up, sequences start at 1 rather than at 0.) For a phrase, the value would be the starting point of where it was found, with "wor" in "Hello world!" returning a value of 7.

If letter you're searching for doesn't exist, then return null or 0.

Actual Behavior

The existing block is the reporter ( letter ( n ) of ( txt ) ) which takes an index and returns the letter at that location, if it exists. There is also < ( txt ) contains ( txt ) > but this only reports whether or not the letter or phrase is in the string at all, as True or False.

Also forgot about the list reporter, item # of ( n ) in ( list ), which is basically the same exact thing, indexing a particular string, but for lists instead of variables.

Steps to Reproduce

Complicated workaround is to use repeat until < condition > block to index each letter sequentially in a string (using a predefined variable starting at 1 and incrementing it with each cycle) until you reach the letter you're looking for, and then you'll have your value. Even then, this really only works with indexing single characters and not phrases containing two or more characters.

[averagewolfie]

Actually, I was going to see if I could make pull request for this block myself, but I can't test the block because I'm unable to compile the fork of scratch-blocks on my computer. (llk/scratch-blocks#1859)

[towerofnix]

You shouldn't make pull requests for large new features (e.g. new blocks) before the Scratch Team says they want the block added - there's a lot of design and testing time they put into blocks before releasing or deciding on them, so generally community PRs on those specifically aren't very useful in practice.

[averagewolfie]

Large feature? The single block, as far as I'm concerned, is just a few lines of code here and there. I even went and looked at another block commit (specifically the < ( txt ) contains ( txt ) > block) for reference. I'm certain that the block I've coded will work. I just have no way to test it. That's really the only thing stopping me at the moment from making the pull request. Once I know it's functioning the way I intend it to, then I will go forward with such discussion as "should this block be officially implemented?"

[towerofnix]

Well, you're right that's certainly not a large feature to implement. (I've written the code for a few blocks myself, including "item # of (value) in (list)", which is essentially the same code as for your suggested block.) The trouble is that it's a large addition to the programming language, and the Scratch Team is very wary to add new blocks. (There have been no new blocks added since 3.0 was released, for instance, and 3.0 came with very few new blocks to the core language (i.e. non-extensions) as well.)

Once I know it's functioning the way I intend it to, then I will go forward with such discussion as "should this block be officially implemented?"

Almost all the time, the ST works the other way around. They figure it's not worth writing the code to implement something if it's not going to be added. While there is a place for implementation before officialization sometimes, namely playtesting (sharing the feature with an organized group of IRL testers and gathering feedback before deciding whether or not to release), that, um... hasn't happened in the past for blocks? (It has for extensions I believe, but that's not entirely relevant here.) And it's not something the ST would do without deciding that they are interested in having a feature implemented in the first place, which they haven't done for this suggested block yet.

(Disclaimer, my opinion: I'm a bit surprised and somewhat frustrated that the ST has been as slow as they are now to actually have design discussions on feature suggestions, share the results publicly, and have things be implemented. But such is such. They're evidently busy on implementing other things, I suppose.)

Also, the ST is presently working on the "extensionification", wherein all the core Scratch blocks are converted into the same format as extensions. (They'll still show up as default categories, mind you - it's just that they're going to written with the same type of code as extensions. This also means future extensions will have access to nearly all the same capabilities as the default Scratch blocks.) It's a pretty big task and it involves, to varying degrees, rewriting the specifications for literally every (non-extension) block in Scratch; so the ST really isn't in the position to take any pull requests which add new blocks right now. Code just isn't useful when it's going to need to be rewritten over the next couple months (or so) anyway.

---

All that said, not being able to work on Scratch 3.0, whether for your own purposes or to resolve issues the ST has labelled "help wanted", does suck. Have you tried running cygwin or a linux subsystem instead of the default windows command prompt? The issue creator there said it didn't help but it's worth a shot, since that seems to be the fix for most other windows users.

Worst case scenario, you can't get scratch-blocks working, which means you can't work on features related to that repo or add new blocks presently. I think Scratch 3.0 can still be built on Windows as long as you use a precompiled version of scratch-blocks instead of building it yourself -- I may be wrong but if you just do npm install scratch-blocks (instead of npm linking it) it should work. Do note that once the extensionification is done, I believe you won't need to modify scratch-blocks to add new blocks anyway - you'd only need to change scratch-vm. That won't be for a while, but still, adding new blocks before it's done probably isn't worth it anyway, so.

[averagewolfie]

Have you tried running cygwin or a linux subsystem instead of the default windows command prompt? The issue creator there said it didn't help but it's worth a shot, since that seems to be the fix for most other windows users.

I have tried using Cygwin, and I did manage with your suggestion to grab blockly_compressed_horizontal.js and blockly_compressed_vertical.js, which were missing prior to this point, but for some reason they still throw "unknown error" although it didn't abort the build this time, and now I'm able to launch the GUI from my local source.

I'll hold off on the pull request for now, but I'll experiment and see if I can code blocks anyway. Maybe I'll wait until this block code revision which you mention takes place before suggesting them.