Scratch

fullmoon wrote:

What about the ability to define a block as "For all sprites" or "For this sprite only"?

That would be the most simple way to solve the first post's question, maybe having a "for all sprites?" button on the right-click menu. That way you can do the same as with variables and lists, IIRC you can set, say, two variables named "a" if each is for their respective sprite. 

Lightnin wrote:

amcerbu wrote:

scimonster wrote:

How?

According to the progress report, procedures will be carried out by "custom blocks."  The procedure itself is stored somewhere else in the code, and by running it, the program calls on that particular section of code.  Not only can procedures be run from another place (like broadcasts), they can also take arguments.  This completely eliminates the need for a broadcast block at all.

Not quite! You still need a way to send messages between sprites, right? And we haven't decided if procedures will be global or not.

+1.

boogernator wrote:

Pause all scripts maybe? We could use one of those!

maybe a pause all scripts and unpause all scripts?
very usefull.

jji7skyline wrote:

I think you should have just the basic blocks in the Standard Scratch version and then have a block download page. But make it simple like when you download add-ins for Firefox or Google Chrome.

Excellent idea! We're considering having a "blocks exchange" (sort of like the Apple App Store) that would allow users to download useful blocks defined by other users. We might even make some of the existing blocks be optional downloads (e.g. the WeDo motor control blocks, which are not useful unless you have a Lego WeDo kit).

fullmoon wrote:

bharvey wrote:

johnm wrote:

I should mention that user-defined reporters have impacts performance and the concurrency mechanism, so there are some technical reasons to not include that feature in Scratch 2.0.

... as I discovered to my dismay in BYOB!  But, John, other languages don't have this problem -- it's just a result of your (as Jens keeps telling me    ) brilliant (but very unusual) design for the evaluator.  When we rewrite BYOB this summer the evaluator will be independent of the GUI code and recursive reporters will be fast.  And you're rewriting the evaluator, too, so you could address the speed problem.

Just out of curiosity, what is it that makes reporters so expensive?

Brian: I re-wrote the evaluator for Scratch 2.0 and got a factor of 50-60 speedup. Not rocket science, just being careful. To be fair, the new evaluator does not yet support block highlighting for single stepping, but I hope I can add that without slowing down the normal case.

Fullmoon: The evaluator currently depends on the fact that all of the built in reporter blocks are atomic operations. They don't contain loops or "wait" operations, and they can't cause a thread switch. Thus, all argument expressions can be recursively evaluated inline; the evaluator does not need to save and restore state during argument evaluation because no thread switches can occur. In contrast with built in reporters, a user-defined reporter may contain an infinite loop or a block that does a "wait", thus forcing a thread switch. The mere possibility of a thread switch would force the Scratch argument evaluator to save and restore state for every expression it evaluates, just in case that expression causes a thread switch.

Of course, it might be possible to optimize the evaluator to avoid the expensive case when it can (although even detecting the fast cases would add some overhead). But my bigger objection to user-defined reporters is precisely that they can introduce a thread switch in any block that takes an argument. Although most users don't need to worry about when thread switches occur, Scratch currently allows thread switches only on "wait" blocks and at the end of loops. This design prevents many of the concurrency errors that can occur in other languages, and it works extremely well. User-defined reporters introduce potential thread switches at unexpected places, thus making concurrency errors more likely.

Concurrency errors are extremely difficult to diagnose and debug, even for the most experienced programmers. (I've sometimes spent days or even weeks looking for a single concurrency error.)

The combination of decreased performance and the potential to introduce concurrency errors makes me very reluctant to introduce user-defined reporters in the first release of Scratch 2.0. I don't rule them out for a future release, but I'd like to see how the Scratch community responds to the ability to define command blocks first. One step at a time.

-- John

Last edited by johnm (2011-04-23 09:08:56)

maciej wrote:

When is scratch 2 coming out its been years and still I go to download and it said 1.4

in along while

user-created blocks should be in a seperate part of the pallete and there should be the names of user-created blocks followed by the blocks that they consist of.

sounds awesome!!!

I think there should be a block where your sprite can go backwards instead of forwards!  <move(10 )steps> backwards! 

horido6 wrote:

I think there should be a block where your sprite can go backwards instead of forwards!  <move(10 )steps> backwards! 

[/blocks]
You can just use a negative number in the number of steps.  So "move -10 steps" will make it move ten steps backward.

rexrex600 wrote:

user-created blocks should be in a seperate part of the pallete and there should be the names of user-created blocks followed by the blocks that they consist of.

+1

Last edited by amcerbu (2011-04-25 19:29:43)

bujui wrote:

Eyedropper tool please make it.

<a href="http://www.danasoft.com"><img src="http://www.danasoft.com/sig/ScratchThing.jpg" border="0"></a><div style="font-family:arial,sans-serif;font-size:11px;"><p>Sign by Danasoft - <a href="http://www.danasoft.com">For Backgrounds and Layouts</a></p></div>

HTML doesn't work in this forum; you need BBCode. Unfortunately, New Scratchers cannot post images or links. 

Lightnin wrote:

Here's the latest Scratch 2.0 Progress Report

Check it out, and then join in the discussion about the best way to do 'Create your own block' in Scratch 2.0 here:

Create your own block blog post wrote:

We’re still in the process of figuring out the best way for Scratchers to create their own blocks, and there are still many questions. For example, if you create a jump block in one sprite, would other sprites be able to use the jump block too? Should the definition script appear in only one sprite -- and, if so, how would people find it? Should you be able to define “jump” differently in different sprites? These are few of the questions we have to think through before we’re ready to put this cool feature in the next version of Scratch.

Do it like the variables. This sprite only, or all sprites!!!

When is the next report coming?