Scratch

Jens wrote:

dasbloekendeschaf wrote:

Hi Jens and Brian. I don't know, if it fits here, but I found a little bug and also have a small suggestion:

-> You can rename the stage
-> New sprites should be undraggable by default

Thanks for mentiong these. Being able to rename the stage is a feature, not a but. You can rename the stage in Scratch, too. (I sometimes rename mine to "deep space" or "island" etc.)

Should new sprites be undraggable by default? That's a good question, because - you're right - most of the time I end up making mine undraggable. However, I also think it would be quite an impediment if you couldn't move them around as you first create them. What do you think?

I vote it should be like Scratch: always draggable in design mode but undraggable by default for presentation mode.

Jens wrote:

You can rename the stage in Scratch, too.

No, you can't...

MathWizz wrote:

Jens wrote:

You can rename the stage in Scratch, too.

No, you can't...

Whoa! You're right, I never noticed... Well, anyway I strongly feel that you should be able to rename any object to anything, so, there you go. This is definitely a feature which I specifically implemented.

Jens wrote:

joefarebrother wrote:

snap! question: Can I access a variable in the dynamic scope if it is also the name of a global variable?

snap! suggestion: a <(variable) is bound (drop-down: lexically/dynamically/at all)> block

At this time hybrid scope doesn't exist, and you can only access the lexical scope. Personally, I think that's exactly the right thing to do, hybrid scope opens up a can of worms of kludges and collisions - as you have found out in your question. But Brian is lobbying hard to put dynamic scape back in, because he wants to use it for local helper functions. So, stay tuned!

Oh well. I can still implement my project using lexical scope like this:

script variables (old value)
set [old value v] to (dynamic variable)
run (script)
set [dynamic variable v] to (old value)

I LOATHE how Scratch handles direction, but its blocks are my only reference for recreating it in Canvas.
Shouldn't

if (opp<0)
{
    direction = 180+(r_to_d(Math.atan((opp/adj))));
}
else
{
    direction = (r_to_d(Math.atan((opp/adj))));
}    
        
scrollX = scrollX + (Math.sin(direction))*adj;
scrollY = scrollY + (Math.cos(direction))*opp;

work ok? (By the way, r_to_d is a function for radians to degrees)

shadow_7283 wrote:

I LOATHE how Scratch handles direction, but its blocks are my only reference for recreating it in Canvas.
Shouldn't

Code:

scrollX =+ (Math.sin(r_to_d(direction))) * speed;
scrollY =+ (Math.cos(r_to_d(direction))) * speed;

work ok? (By the way, r_to_d is a function for radians to degrees)

Fix'd. What is this for?

MathWizz wrote:

shadow_7283 wrote:

I LOATHE how Scratch handles direction, but its blocks are my only reference for recreating it in Canvas.
Shouldn't

Code:

scrollX =+ (Math.sin(d_to_r(direction))) * speed;
scrollY =+ (Math.cos(d_to_r(direction))) * speed;

work ok? (By the way, r_to_d is a function for radians to degrees)

Fix'd. What is this for?

fix'd again

joefarebrother wrote:

MathWizz wrote:

shadow_7283 wrote:

I LOATHE how Scratch handles direction, but its blocks are my only reference for recreating it in Canvas.
Shouldn't

Code:

scrollX =+ (Math.sin(d_to_r(direction))) * speed;
scrollY =+ (Math.cos(d_to_r(direction))) * speed;

work ok? (By the way, r_to_d is a function for radians to degrees)

Fix'd. What is this for?

fix'd again

Wow. I failed. xD

Is this becomming offtopic or what?

Thanks for the help guys. 
I don't know what it is, but Chrome's interpreter never lets me use =+ .
EDIT: Look at this weird behavior... (right click)

Last edited by shadow_7283 (2012-08-15 13:18:54)

joefarebrother wrote:

isn't it += ?

Just citing your fixes. 

Hardmath123 wrote:

Jens wrote:

dasbloekendeschaf wrote:

Hi Jens and Brian. I don't know, if it fits here, but I found a little bug and also have a small suggestion:

-> You can rename the stage
-> New sprites should be undraggable by default

Thanks for mentiong these. Being able to rename the stage is a feature, not a but. You can rename the stage in Scratch, too. (I sometimes rename mine to "deep space" or "island" etc.)

Should new sprites be undraggable by default? That's a good question, because - you're right - most of the time I end up making mine undraggable. However, I also think it would be quite an impediment if you couldn't move them around as you first create them. What do you think?

I vote it should be like Scratch: always draggable in design mode but undraggable by default for presentation mode.

Agree.

PS1: If the stage should be renamable, I have a little improvement idea: I renamed it into "Scratch", opened another sprite and then returned to the stage. The name went to the default one. It's because I didn't press enter before going to and editing the sprite. I mean, many people will forget to press it and then think it's a bug. (BTW: Renaming a sprite in Scratch 1.4 is like in my suggestion)

PS2: Why did you change the button graphics of the sprite rotation options? It doesn't look that clearly anymore as it did in Scratch 1.4 or an earlier alpha of snap.

joefarebrother wrote:

Oh well. I can still implement my project using lexical scope like this:

script variables (old value)
set [old value v] to (dynamic variable)
run (script)
set [dynamic variable v] to (old value)

This technique (called FLUID-LET in the literature) works only if the variable is globally bound.  The whole point of local variables (well, okay, part of the point) is to keep from having to clutter up your global environment with temporarily-useful variables.

There are many successful languages that are lexically scoped, and many that are dynamically scoped.  (These days the ones you've heard of are lexically scoped, because that makes compiler optimization easier.)  The thing that I want to do, conceptually a little more complicated, is to allow the two scoping disciplines to coexist.  My proposal ("hybrid scope") is that, to avoid name capture bugs, the lexical environment -- which includes global bindings -- wins.  Snap! should be lexically scoped, except just when we're about to give a "no such variable" error message, we instead look in the dynamic environment.  Because we don't look there except for what would otherwise have been an error, it won't slow down lexically scoped programs, and it will allow the use of unique names with dynamic scope.  Best of both worlds.

snap! wrote:

Save Failed: Type Error: Object doStop has no method 'toXML'

Why? It saved before and i only changed one block. (I changed a call to a run)


Also, it is REALLY slow opening projects with a URL-embedded XML file.

Last edited by joefarebrother (2012-08-16 03:40:26)