miniepicness wrote:

Support, I dont want to have to remake the block that you used:

<<(join (letter (1) of (\[scratchblocks\] command)) (join (letter (2) of (\[scratchblocks\] command)) (join (letter (3) of (\[scratchblocks\] command)) (join (letter (4) of (\[scratchblocks\] command)) (letter (5) of (\[scratchblocks\] command)))))) = [Ask []> and <[\] and wait] = (join (letter (length of (\[scratchblocks\] command)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (1)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (2)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (3)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (4)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (5)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (6)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (7)) of (\[scratchblocks\] command)) (join (letter ((length of (\[scratchblocks\] command)) - (8)) of (\[scratchblocks\] command)) (letter ((length of (\[scratchblocks\] command)) - (9)) of (\[scratchblocks\] command)))))))))))>>

every time I want to do its action

forever
Support ::pen
end

TheMonsterOfTheDeep wrote:

So, for anybody who's curious, here is the full workaround, that is the absolute best approximation to the block suggested in the OP, which stores its output in ‘result’:

{several long and therefore probably laggy workarounds}

And if we had custom reporters, this block would need no variables at all.

To compare, the speed of all three blocks is pretty good for small strings, and the second one should work for almost anything that you would actually need to do in Scratch. It's likely that whatever block the Scratch Team implemented would also be slow on ridiculously large strings, simply because creating substrings, unless they are interned, is by nature an O(n) operation.

My point with this post is that OP's argument that the workaround is laggy / slow is basically moot; although this custom block only works in a single thread, if you are doing multi-threaded string manipulation you are already probably doing something wrong.

I'm honestly not sure where I stand in terms of better string manipulation features in Scratch - certainly they are useful, but figuring out how to implement them myself was honestly one of the best critical thinking exercises I ever received from Scratch. It's important to be able to know how these sorts of operations work on the inside, as it allows you to see how slow they really are - I think people learning to implement them manually is a good experience, and I think that it is not at all bad that Scratch provides it.

I especially think that if we do ever get custom reporters, we should not implement blocks like these - if there were custom reporters (and maybe local variables) than implementing these blocks by hand would have very little negative effect, while it would have a huge educational effect.

Maybe not though. I am using anecdotal evidence here, but I don't think my point is entirely invalid.

1. what I used
   
2. repeat blocks and variables
   
3. being recursive functions
   

1. no less laggy than what I'm using (because they're the same)
   
2. First of all, it creates this completely unnecessary variable that just clutters up the data section. Also, if two of these scripts are running at the same time, and they use the same variable, that would really mess things up. Also, repeat blocks pause between each repetition, so that would make it take longer.
   
3. Calling custom blocks generates lag.
   

move () steps
if on edge, bounce
change x by ()
set x to ()
change y by ()
set y to ()
turn cw () degrees
turn ccw () degrees
go to [ v]
say [] for (2) secs
think [] for (2) secs
next costume
next backdrop
change size by ()//or alternately, set size to () %
play sound [ v]
rest for () beats
change volume by ()//or alternately, set volume to () %
change tempo by ()//or alternately, set tempo to () bpm
if <> then
end
wait until <>
repeat until <>

end
(distance to [ v])
(foo)
(☁ score)
change [ v] by (0)//or alternately, set [ v] to []
add [] to [list v]
<[ v] contains [thing] ?>
(() + (0))
(() * (0))
<[] < []>// or alternately, get rid of <[] > []>
<[] = []>
<<> and <>>//or alternately, get rid of <<> or <>>
(round ())
([floor v] of (9))//or alternately, get rid of ([ceiling v] of (9))
([10 ^ v] of (9))//or alternately, get rid of ([e ^ v] of (9))
([log v] of (9))//or alternately, get rid of ([ln v] of (9))

([abs v] of (9))
forever

end
go to x: () y: (0)
point towards [ v]
(x position)
(y position)
(direction)
<<> and <>>
<<> or <>>
<not <>>
(() / (0))//or alternately, (() - (0))
(length of [ v] :: list)//or alternately, replace item ( v) of [list v] with [thing]
change [ v] effect by (25)//or alternately, set [ v] effect to (0)
change pen color by ()//or alternately, set pen color to ()
change pen shade by ()//or alternately, set pen shade to ()
change pen size by ()//or alternately, set pen size to ()
when green flag clicked
repeat ()

end
wait () secs
stop [all v]
stop [this script v]
(timer)
reset timer
(days since 2000)
(() mod (0))//or alternately, getting rid of ([floor v] of (9)) AND ([ceiling v] of (9))
([sin v] of (9))//or alternately, ([cos v] of (9))
([tan v] of (9))
([asin v] of (9))//or alternately, ([acos v] of (9))
([sqrt v] of (9))
broadcast [ v] and wait
switch backdrop to [ v] and wait
(volume)
(tempo)

<[] < []>
<[] = []>
<[] > []>

dvargasews wrote:

TheMonsterOfTheDeep wrote:

several long and therefore probably laggy workarounds

First of all, even if custom reporters are added, they'll have to use one of the following:

• what I used: no less laggy than what I'm using (because they're the same)
  

repeat blocks and variables: First of all, it creates this completely unnecessary variable that just clutters up the data section. Also, if two of these scripts are running at the same time, and they use the same variable, that would really mess things up. Also, repeat blocks pause between each repetition, so that would make it take longer.

TheMonsterOfTheDeep wrote:

if you are doing multi-threaded string manipulation you are already probably doing something wrong.

• being recursive functions: Calling custom blocks generates lag.
  

Also, by your “forcing Scratchers to think to get blocks” logic, we could either get rid of all of these blocks:

TheMonsterOfTheDeep wrote:

dvargasews wrote:

TheMonsterOfTheDeep wrote:

several long and therefore probably laggy workarounds

Uh, no, these are not laggy. Length of script does not correlate with lag in any real way. Don't believe me? I have all the workarounds in this project, please go try them for yourself.

TheMonsterOfTheDeep wrote:

First of all, even if custom reporters are added, they'll have to use one of the following:

• what I used: no less laggy than what I'm using (because they're the same)
  

I already take issue with this because your workaround could not possibly be used in a custom reporter very effectively, as it can only use a preset number of characters.

TheMonsterOfTheDeep wrote:

repeat blocks and variables: First of all, it creates this completely unnecessary variable that just clutters up the data section. Also, if two of these scripts are running at the same time, and they use the same variable, that would really mess things up. Also, repeat blocks pause between each repetition, so that would make it take longer.

Let's see:
- Unnecessary variable: I also dislike using a variable, but it's not really a huge issue. Also, if we had local variables, this problem would not exist.
- Using two blocks at the same time: let me refer you to my original post

TheMonsterOfTheDeep wrote:

if you are doing multi-threaded string manipulation you are already probably doing something wrong.

TheMonsterOfTheDeep wrote:

- Repeat block pauses: not with run without screen refresh it doesn't.

TheMonsterOfTheDeep wrote:

• being recursive functions: Calling custom blocks generates lag.
  

Okay, but it's not enough lag to be noticeable unless you are manipulating very big strings.

TheMonsterOfTheDeep wrote:

However, if you are doing string manipulation, it's likely that you aren't going to be manipulating strings over 10240 characters, as that is the join block limit.

Also, by your “forcing Scratchers to think to get blocks” logic, we could either get rid of all of these blocks:

duckboycool wrote:

Like @TheMonsterOfTheDeep said, workaroundable, and doesn't lag at all. No support.

dvargasews wrote:

duckboycool wrote:

Like @TheMonsterOfTheDeep said, workaroundable, and doesn't lag at all. No support.

It lags; just too little to notice if used ONCE.

duckboycool wrote:

dvargasews wrote:

duckboycool wrote:

Like @TheMonsterOfTheDeep said, workaroundable, and doesn't lag at all. No support.

It lags; just too little to notice if used ONCE.

Is there a huge point of making a block that likely won't even lag less than a workaround when said workaround barely lags?

go to [Sprite1 v]
go to x: ([x position v] of [Sprite1 v]) y: ([y position v] of [Sprite1 v])

(letter () of [])

go to [ v]

duckboycool wrote:

Valid point, but that is much more used with inexperienced scratchers than

(letter () of [])

And this would likely be even less used. Although I wouldn't be opposed to removing the

go to [ v]

block, that's a different topic.

dvargasews wrote:

duckboycool wrote:

Valid point, but that is much more used with inexperienced scratchers than

(letter () of [])

And this would likely be even less used. Although I wouldn't be opposed to removing the

go to [ v]

block, that's a different topic.

Why should it be removed? It takes only a third of the time to run as the alternative that I gave.

duckboycool wrote:

dvargasews wrote:

duckboycool wrote:

Valid point, but that is much more used with inexperienced scratchers than

(letter () of [])

And this would likely be even less used. Although I wouldn't be opposed to removing the

go to [ v]

block, that's a different topic.

Why should it be removed? It takes only a third of the time to run as the alternative that I gave.

It has some very easy workarounds that don't take more time at all.

duckboycool wrote:

It is still a fraction of a second, and the workarounds for this block are not 3 times as laggy as the block would be.

go to [ v]

([x position v] of [Sprite1 v])

([y position v] of [Sprite1 v])

go to x: () y: (0)

go to [Sprite1 v]
go to x: ([x position v] of [Sprite1 v]) y: ([y position v] of [Sprite1 v])

dvargasews wrote:

-snip

dvargasews wrote:

They're not laggy if used once, but my project will be heavily reliant on them.

dvargasews wrote:

I do not know that Scratch 3.0 will not include a “launch” block (like Snap!'s).

dvargasews wrote:

I can't do run without screen refresh in my project because scripts don't automatically run without screen refresh in Snap!

dvargasews wrote:

or using it a lot, which my project will do.

dvargasews wrote:

I have no idea what users of the finished project will input.

dvargasews wrote:

How is what I'm suggesting advanced? To me, advanced is like https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/topic/235390/
Compared to that, what I'm suggesting is child's play.

TheMonsterOfTheDeep wrote:

dvargasews wrote:

They're not laggy if used once, but my project will be heavily reliant on them.

Really? I did a quick benchmark where I ran the block 100,000 times and grabbed 50 characters, and the longest it took (with run without screen refresh) was 15 seconds, which was with the recursive block. The others were about 8 seconds. Yes, this is significantly longer than something like JS - where this same benchmark takes 1 ms (I think), but I still find it hard to believe that it's a real problem.

TheMonsterOfTheDeep wrote:

dvargasews wrote:

I do not know that Scratch 3.0 will not include a “launch” block (like Snap!'s).

TheMonsterOfTheDeep wrote:

I can't tell what you're trying to say here…

dvargasews wrote:

I can't do run without screen refresh in my project because scripts don't automatically run without screen refresh in Snap!

…What? What do you mean? You're making a suggestion for Scratch; I don't see how Snap! is at all relevant.

TheMonsterOfTheDeep wrote:

dvargasews wrote:

or using it a lot, which my project will do.

Could you give some estimate of how much you are going to need this block? As it were I am skeptical that having to workaround this block manually will cause enough lag relative to the rest of your project to make it unuseable.

TheMonsterOfTheDeep wrote:

dvargasews wrote:

I have no idea what users of the finished project will input.

My point was that if you are using the join block at all, you will not have strings more than 10240 characters, because the join block will not return strings that are longer than 10240 characters. (I think - the number might be slightly different, but it's very close).

TheMonsterOfTheDeep wrote:

dvargasews wrote:

How is what I'm suggesting advanced? To me, advanced is like https://scratch-mit-edu.ezproxyberklee.flo.org/discuss/topic/235390/
Compared to that, what I'm suggesting is child's play.

When did I say that what you are suggesting is advanced? What I said is that data manipulation - which is what you need this block for - is generally an advanced topic.

TheMonsterOfTheDeep wrote:

I don't want to do more quoting because it's tiring, but there's two points I want to discuss more:

a) Why is your project doing string manipulation in multiple threads? That's not going to work out very well. If you only do string manipulation in one thread than the workarounds I have posted are sufficient. Sure, it doesn't workaround the block at a fundamental level - but I can't imagine a situation where a project would need this block in multiple threads.

TheMonsterOfTheDeep wrote:

b) I've become a bit too fixated on the phrase “data manipulation.” What I mean is doing the particular kind of data manipulation you would need this sort of block for - that is, parsing, and related topics. Those things are advanced topics - at least, they're advanced relative to Scratch.

TheMonsterOfTheDeep wrote:

But you still haven't answered my question about why Snap! is relevant,

TheMonsterOfTheDeep wrote:

or given an estimate on how much you would actually need this block.

dvargasews wrote:

<snipped the unimportant parts>

TheMonsterOfTheDeep wrote:

dvargasews wrote:

I do not know that Scratch 3.0 will not include a “launch” block (like Snap!'s).

It runs two scripts at once.

TheMonsterOfTheDeep wrote:

I can't tell what you're trying to say here…

dvargasews wrote:

I can't do run without screen refresh in my project because scripts don't automatically run without screen refresh in Snap!

…What? What do you mean? You're making a suggestion for Scratch; I don't see how Snap! is at all relevant.

Whoops! Fixed that.

TheMonsterOfTheDeep wrote:

dvargasews wrote:

or using it a lot, which my project will do.

Could you give some estimate of how much you are going to need this block? As it were I am skeptical that having to workaround this block manually will cause enough lag relative to the rest of your project to make it unuseable.

Add the number of blocks that you use in a typical project to double the number of inputs in said project to get a bare minimum.

TheMonsterOfTheDeep wrote:

dvargasews wrote:

I have no idea what users of the finished project will input.

<snipped the unimportant parts>

My project will be heavily reliant on either this or the workaround that I use for input-evaluation.

TheMonsterOfTheDeep wrote:

Now I know that the amount you in particular would need this block is rather irrelevant, as it's possible that there is somebody out there that absolutely does need it - but I can't imagine such a situation so you'll need to help me out there. If your project is actually slow enough to warrant the necessity of this block than I will probably reverse my position, but I seriously doubt that that is the case. I would also reverse my position presented an example of any other project where this block is an absolute necessity - but I'm pretty sure that such a project doesn't really exist, or is very rare.