Scratch

RedRocker227 wrote:

Greenatic wrote:

RedRocker227 wrote:

It'd be a little harder to make, but it'd be cool if there was

<[Hello] is a word in [English v]?>

as well.

They would have to create a dictionary for all the languages.   

Maybe just the main ones then, such as French, German, etc. 

Maybe.  But first they would need to get the English ones working.   

I have another idea. How about a pick random word block?

I will support also.

I support!

Just grab an excessively large list of dictionary words and use the import list feature to load it into a giant word database.

Just kidding, I support it.

bump

Pecola1 wrote:

I WOULD vote yes, this would be a cool feature.
However it would be too strange of a block, if you know what i mean, its like from the net scratch mod, there are things in it that only seem useful in certain projects.

It would not be the easiest block to program for the ST either, it would make scratch lag a lot with all those words in it, UNLESS, they had it read from an internet page as if it WAS a list, but that would mean the block could take a minuet or two to actually respond.    It would also mean if your project is too big, it could freeze scratch, thinks with a lot of space like that either take a LOOOONG time to load, or they will crash and/or freeze scratch. 

So I don't support.

OK, let me break this down and see if I can convince you:

Pecola1 wrote:

I WOULD vote yes, this would be a cool feature.
However it would be too strange of a block, if you know what i mean, its like from the net scratch mod, there are things in it that only seem useful in certain projects.

Should we then get rid of the functions/trigonometry block?  Or touching color blocks?  Like this block, those blocks give unique functionality that is nearly impossible otherwise, but they're not always used.

Pecola1 wrote:

It would not be the easiest block to program for the ST either, it would make scratch lag a lot with all those words in it, UNLESS, they had it read from an internet page as if it WAS a list, but that would mean the block could take a minuet or two to actually respond.    It would also mean if your project is too big, it could freeze scratch, thinks with a lot of space like that either take a LOOOONG time to load, or they will crash and/or freeze scratch. 

I'm not suggesting brute-forcing the dictionary.  Everybody knows that that's a very bad idea.  We would have lists for "aa"s, "ab"s, ... "az", "ba"s, and so on until "zz"s.  That will create less words per list, and if there are still too many, they could make them less letter-specific ("aaa").  Not all lists will be used, but it will minimize the number of words that need to be scanned for each time the block is used.

Pecola1 wrote:

Greenatic wrote:

OK, let me break this down and see if I can convince you:

Pecola1 wrote:

I WOULD vote yes, this would be a cool feature.
However it would be too strange of a block, if you know what i mean, its like from the net scratch mod, there are things in it that only seem useful in certain projects.

Should we then get rid of the functions/trigonometry block?  Or touching color blocks?  Like this block, those blocks give unique functionality that is nearly impossible otherwise, but they're not always used.
The function block is actually used a lot... but for more advanced users (unlike me XD) the color blocks help newer users, i used them a LOT before i started using variables. (I used to simply use color touching color rather than sprite touching sprite, but now i use variables) It is also very useful for sensors.

However these word blocks would only be used in times when you would have a user type a story, and you want spell check. There are a few other uses... but i cant rlly think of many. XD
People don't always use the MIDI blocks, or tempo.  So let's say it's not necessary too and get rid of it.   

Pecola1 wrote:

It would not be the easiest block to program for the ST either, it would make scratch lag a lot with all those words in it, UNLESS, they had it read from an internet page as if it WAS a list, but that would mean the block could take a minuet or two to actually respond.    It would also mean if your project is too big, it could freeze scratch, thinks with a lot of space like that either take a LOOOONG time to load, or they will crash and/or freeze scratch. 

I'm not suggesting brute-forcing the dictionary.  Everybody knows that that's a very bad idea.  We would have lists for "aa"s, "ab"s, ... "az", "ba"s, and so on until "zz"s.  That will create less words per list, and if there are still too many, they could make them less letter-specific ("aaa").  Not all lists will be used, but it will minimize the number of words that need to be scanned for each time the block is used.
Thats actually kinda what i meant... only i would have the words all on one page so there's less memory space. XD Like you (or was it someone else) said, its a lot of words, just like in a regular list if you were to put every word into it.

Why not just do all that yourself, make a list for aas abs acs etc.    See what i mean, just as much memory (if not more) and a lot more time.

You could probably get a list offline which had every word in one txt file... but like you said, it would be a lot of space if it was put into a list, and having it read from offline would make it even worse.
Alright then, let's make people code their own MIDI synthesizers too!  Just make a sound for every note of every instrument...

Not convinced 

PencilFactory wrote:

if <[ ] is a word?> 
say <random word>
else
if<[ ] is a [verb v]?>
say (pick random [a] to [z])

Is that a support?   

Mokat wrote:

Support!
I have a question though: what category would this block be under?

Thanks!   

It would probably be in Operators.

CheeseMunchy wrote:

Seems like they would be pretty complicated to make. 

Scratch blocks can be very complicated without causing problems.  This is the code for <touching color [ ]?>:

touchingColor: t1 
    | t2 t3 t4 t5 t6 |
    t2 _ self bounds intersect: owner bounds.
    t2 area = 0 ifTrue: [^ false].
    t3 _ self imageForm asFormOfDepth: 16.
    t4 _ Form extent: t3 extent depth: 1.
    t5 _ Bitmap new: (1 bitShift: (t3 depth min: 15)).
    t5 atAllPut: 1.
    t5 at: (Color transparent indexInMap: t5)
        put: 0.
    t4
        copyBits: (t2 origin - self position extent: t2 extent)
        from: t3 form
        at: 0 @ 0
        colorMap: t5.
    t6 _ owner
                patchAt: t2
                withoutWatchersAnd: self
                andNothingAbove: false.
    t5 atAllPut: 0.
    t5 at: (t1 indexInMap: t5)
        put: 1.
    t4
        copyBits: t6 boundingBox
        from: t6
        at: 0 @ 0
        clippingBox: t6 boundingBox
        rule: Form and
        fillColor: nil
        map: t5.
    ^ (t4 tallyPixelValues at: 2)
        > 0

Last edited by Greenatic (2012-03-05 18:09:45)

sorry, this seems just too useless, and too much about only one type of project. and also, how would you implement this? 
online API: too slow
offline: there are too many words, and can't be updated often. what about words like planking or scratcher, which don't show up in normal dictionaries?

also no support for other language