Scratch

markyparky56 wrote:

I wonder, would this be harder or easier if this wasn't in squeak?

There's a tradeoff involved.  Squeak makes the GUI relatively easy.  The actual evaluation of BYOB programs would be way easier in Scheme.  Most other languages (Java, C++, all those) would make the whole thing harder, most likely.

bharvey wrote:

nXIII wrote:

Sorry, I always mess up "call" and "run"

So was that your problem, or does it fail with RUN too?

Er ... I forget. Sorry, I'll have to open it again tomorrow.

bharvey wrote:

The bug-reporting link on the BYOB web page now links to a Bugzilla server at http://byobugs.com and it allows anonymous bug reporting so I think it's now legal for under-13-year-olds to use it.     (But I think it does log your IP address.)

Because I'm SO scared of Jens and Brian tracking me down using my IP and email and kidnapping me for exposing so many glitches in the BYOB program. 

JENS IS BACK!!!

2.99.014, mostly improvements to the debugger.

nXIII wrote:

Ugh, I tried to send universal setters to Jens but my email program refuses to attach the image!

Try zipping the image first?  You never know...

nXIII wrote:

Good suggestion, but it still won't do it...

Check your inbox.

bharvey wrote:

New image 2.99.015 with more debugger improvements, plus a new rule for handling events: If a script is already running because of a previous event of the same type, the new event does not restart the script, but is just ignored.

Does that affect broadcasts as well? If not, it should!

Jens wrote:

shadow_7283 wrote:

Does that affect broadcasts as well? If not, it should!

Yes, it affects broadcasts (key pressed events already behave like this in normal Scratch). What's new in 2.99.015 is that every thread (script) gets fully completed before it can be restarted. This appears to be the right thing for CS projects and for animations, but personally I do like Scratch's current rule better, because it makes it easy to create interactive music projects where you can e.g. pick a guitar string arbitrarily.

That's why there's a new experimental block in 2.99.015 labelled

     STOP ALL SCRIPTS FOR [aMessage]

that will force quit any running scripts hatted by a "When I receive [aMessage]" block.

But we're still discussing this. Chances are we'll take that new stop block out again, revert the standard to the "Scratch compatible" thread reentrancy rule and just offer the "ignore mode" option in the EDIT menu.

Which would you prefer?

Hmm... it depends. I could see how both methods of evaluation could come in handy. It think it would be nice to have a couple blocks to control them. It seems that I always end up using a variable when broadcasting messages. Sometimes, it happens when I'm using "repeat until" at the end of a message. Really, I would just like it to be inerupted if a certain condition is true. But I always end up creating another if statment surrounding all broadcasts to wait until that condition is met. Not very efficient. However, sometimes my projects depend on the fact that the broadcasts can be interupted and restarted, especially when they use "forevers" at the end of their script. So I think it would be nice to have blocks to control this.

However, I don't really think I like Scratch's method for message passing, period. It always annoys me how I can't have a message available for just a single sprite (like variables!) or just a couple. I almost always end up using boolean variables as an alternative and set them to 1 (representing true) if a message is being passed and 0 (representing false) if a message has been completed, or started (which eliminates the need for the blocks you created). Is there anyway BYOB could include a message passing system more like variables?

By the way, I'm glad your back! 

Last edited by shadow_7283 (2010-06-09 09:43:56)

Jens wrote:

But we're still discussing this. Chances are we'll take that new stop block out again

I'll just go make a duplicate of the 2.99.015 image file...

Using Elements, if I create a message send of open to Workspace I get a workspace into which I can type. However, trying to evaluate/print what I've typed doesn't work.

If I do the same in a Workspace in Squeak it does.

Is this locked down in some way or is there something more to do with the Scratch 'layer'?

I'd like to be able to show BYOB going all the way up from simple turtle type activities as in Scratch, out to Smalltalk, then back into the first class facilities of BYOB (and I quite often like typing rather than dragging and dropping as with elements as I sometimes suffer from wrist strain if I do too much)

Last edited by jstout (2010-06-09 16:43:58)

nXIII wrote:

I still don't get the reason for this... it should launch the script that is in the selected sprite's variable in a separate thread, BUT EXECUTE IT FOR THE SENDING SPRITE. It should not be a special-evaluation rule.

I see your point, in principle.  But it would be messy.  Consider: why did the programmer make this method be local to a given sprite?  Most likely, because it makes reference to that sprite's private state variables!  Otherwise it could just be a global block and there would be no need to use the [<method> OF <sprite>] block.  So, what you're asking for would work only if the calling sprite knows about and duplicates the called sprite's local variables.

And since the thing that's easy to specify and implement happens also to be the thing that programmers really want anyway -- the ability to send a message to another specific sprite -- we were happy to run with it.

The way to make it make sense theoretically is to understand variable references in a sprite-local block as lexically bound; we know as soon as the block is defined exactly which variable is meant by this variable name.  So if you don't like thinking about running the method "in" the other sprite, then don't think of it as "in" any sprite at all; just think of [i]the method itself]/i] as including references to specific variables, in the same way that methods in the explicit-dispatch-procedure style of OOP know which of several instance variables of the same name to use.

EDIT:  The lexical scoping of variables is compromised a little in BYOB in order to make it possible to duplicate a sprite (or just drop one script onto another sprite) and still find local variables.
If the variable referred to in a script doesn't belong to the current block, then BYOB searches through the current lexical scope for a variable with tha same name and reattaches the orange blob to the new variable.

Last edited by bharvey (2010-06-09 17:33:21)

xly wrote:

I've just started to explore what I call "hybrid functions"

Instead of the WAITs you could use BROADCAST to synchronize.

WHEN I RECEIVE <allmes>
RUN <RED>
BROADCAST <reddone>

WHEN I RECEIVE <reddone>
RUN BLUE
BROADCASY <bluedone>

WHEN I RECEIVE <bluedone>
RUN GREEN