Discuss Scratch

SimpleScratch
Scratcher
100+ posts

Snap! user discussion

Hi
I haven't used Snap much so this has probably been asked/answered a thousand times but why is there no visual difference between local and global variables in Snap?

or is it just my eyesight in my old age

Simon
Dale_Mahalko
New to Scratch
48 posts

Snap! user discussion

How do I select a color and then plot a single 1-pixel point?

It doesn't work to move a sprite and then just do “Pen Down / Pen Up”.

http://snap.berkeley.edu/snapsource/snap.html#present:Username=lhs-dmahalko&ProjectName=plot%20points

Dale_Mahalko
New to Scratch
48 posts

Snap! user discussion

When scanning the keyboard for keypresses, why can't I detect UPPERCASE, the space bar, or any symbols `~!@#$%^&*()-=_+\{}|;':",./<> ….?

This does not work as I would expect.

http://snap.berkeley.edu/snapsource/snap.html#present:Username=lhs-dmahalko&ProjectName=Detect%20any%20keypress
bharvey
Scratcher
1000+ posts

Snap! user discussion

SimpleScratch wrote:

why is there no visual difference between local and global variables in Snap?
You mean sprite-local variables, or procedure-local ones?

There is a difference in the variable watchers on the stage – the label says if it's local. I guess we should put some visual representation of sprite-localness in the palette, maybe a little picture of the sprite next to the orange blob. My feeling is that actual code, where a variable is used, is already pretty crowded. Maybe we should compromise, and when you right-click an orange blob the menu should tell you what flavor it is.

bharvey
Scratcher
1000+ posts

Snap! user discussion

Dale_Mahalko wrote:

How do I select a color and then plot a single 1-pixel point?
You have to say MOVE 1 STEPS. I think this is a misfeature and you should really say MOVE 0 STEPS, because MOVE n STEPS should draw n+1 pixels.

Actually I'm confused about the behavior. Here's MOVE 1 STEPS:

and here's MOVE 100 STEPS:

It seems to me that the former covers one pixel, from x=0 to 0, whereas the latter covers 101 pixels, .

bharvey
Scratcher
1000+ posts

Snap! user discussion

Dale_Mahalko wrote:

When scanning the keyboard for keypresses, why can't I detect UPPERCASE, the space bar, or any symbols `~!@#$%^&*()-=_+\{}|;':",./<> ….?
You can detect the space bar – that's the default in the WHEN block and the Sensing block.

As for the others, we inherited the menu from Scratch. But it does have an “any key” item. What's missing is a reporter holding the most recent keypress. (Although, do you want to include modifier keys as keys (shift, control, etc.)? Here's the best I could do right now:


Edit: But as you noted, it doesn't work for shifted characters.

Last edited by bharvey (Sept. 5, 2017 00:16:00)


Dale_Mahalko
New to Scratch
48 posts

Snap! user discussion

“Move 1” still plots a 2-pixel line.

But after experimenting a bit more, I found a hack solution. It can be told to move less than 1 pixel, and this then draws a 1-pixel point
Move 0.01
Change Y by 0.01
Change X by 0.01

all draw a 1-pixel point.
SimpleScratch
Scratcher
100+ posts

Snap! user discussion

There is a difference in the variable watchers on the stage – the label says if it's local.

Ta

At least I can find out which variables are what scope by doing that

Having played around a bit more I can see that Snap places local vars below the global vars just like Scratch - its just missing the little line that Scratch uses to highlight the demarcation

Maybe it used to be there but has gone AWOL

Simon
bharvey
Scratcher
1000+ posts

Snap! user discussion

SimpleScratch wrote:

Having played around a bit more I can see that Snap places local vars below the global vars just like Scratch - its just missing the little line that Scratch uses to highlight the demarcation
Hmm. Not for me. It puts the variables in the palette in order of creation.

SimpleScratch
Scratcher
100+ posts

Snap! user discussion

mm
if I create in this order
A (for all sprites)
B (for all sprites)
C (for all sprites)
D (for this sprite)
E ((for this sprite)
F (for all sprites)

I get this order
D
E
A
B
C
F

And I've just noticed that Snap has reversed what Scratch does - it puts the locals first and the globals second - xkcd927

Last edited by SimpleScratch (Sept. 5, 2017 13:41:40)

Dale_Mahalko
New to Scratch
48 posts

Snap! user discussion

I find variable order of creation incredibly annoying and disorganized. How can I alphabetize the variable list?

Due to the lack of identification of one variable type from another, plus no built-in way to do constants, I have just accepted that I need to do all the labeling myself in the naming, and I can make it work the way I want anyway regardless of the clunky user interface.

Global variable: G.*
Local Sprite variable: LS.*
In-script Local variable: L.*

Global Constant: GC.*
Local Sprite Constant: LSC.*
In-script Local Constant: LC.*

I can also do fake object oriented design, just because things are easier to read that way. I suspect that this is probably what people did before object oriented programming officially existed, and someone then decided to formalize it into a real thing that the compiler understands.

GC.Game.MapData
GC.Game.SpriteList
GC.Game.PointsList

And this helps with the problem that you cannot pass variables to sprites when you send messages to them to do something, so there needs to be a way to separate out these message passing global variables from everything else.

Global sprite message: GSM.*

Messages sent between sprites are named this way.
Variable data being sent between sprites are named this way.

bharvey
Scratcher
1000+ posts

Snap! user discussion

SimpleScratch wrote:

And I've just noticed that Snap has reversed what Scratch does - it puts the locals first and the globals second
Oh, right, that didn't even occur to me as something to test for.

bharvey
Scratcher
1000+ posts

Snap! user discussion

Dale_Mahalko wrote:

And this helps with the problem that you cannot pass variables to sprites when you send messages to them to do something, so there needs to be a way to separate out these message passing global variables from everything else.
Whoa! In Snap! you don't have to ask a sprite to do something with BROADCAST. You do this:

The first input to OF, if it's a fixed command as in this example, has to be explicitly ringified. The second input can be a sprite name, as here, or a computed actual sprite (e.g., an item of MY NEIGHBORS). The 2nd (and more if needed) input(s) to RUN can be any expression, which will be computed in the context of the calling sprite. (An expression with variables in the first input to OF will be computed in the called sprite in 4.1.)

I think you're thinking too much about syntax, rather than semantics. We can do OOP, it just doesn't use the syntax to which you're accustomed.

As for variables, once you start down that road of squeezing syntax into their names, there's no stopping. How about LS.INTEGER.foo? But, whatever floats your boat.

Dale_Mahalko
New to Scratch
48 posts

Snap! user discussion

Um, well, it looks like this language is basically your baby. You are the architect, and if you're not going to do anything to obviously show the difference between the variable types then it falls on me to do something to make it more obvious to myself, because right now this user interface offers me nothing.

A fake identifier for integers or longs has no purpose because there's no way to define that. I have no clue how to make a string-only variable, and there is no useful reason to go this far because casting isn't possible anyway, and the language does it automatically.

Constants are a fundamental enough concept that they can be identified as I am doing, even if the language offers no direct support, because you don't need to do anything with it except don't modify it once it is created, which is how constants normally work.
PullJosh
Scratcher
1000+ posts

Snap! user discussion

Dale_Mahalko wrote:

Um, well, it looks like this language is basically your baby. You are the architect, and if you're not going to do anything to obviously show the difference between the variable types then it falls on me to do something to make it more obvious to myself, because right now this user interface offers me nothing.
If you ever have a feature idea that you think is really critical, the most helpful thing you can do is submit a pull request. Solving problems yourself lets you do things on your own timeline, rather than someone else's.

Dale_Mahalko
New to Scratch
48 posts

Snap! user discussion

Well, I don't yet know Javascript well enough to offer a direct change to this code for how the UI works. Though I'd probably just extend the outer “variable name bubble” to the left a bit and stick these letter prefixes into the bubble to the left of the editable variable name.

https://i.imgur.com/4owHysv.png

I see that constants can also be named in the more typical all-uppercase naming manner.. that works also without any explicit support for it.
bharvey
Scratcher
1000+ posts

Snap! user discussion

Dale_Mahalko wrote:

Um, well, it looks like this language is basically your baby.
Much more Jens's than mine.

Probably we should bring back the dividing line between globals and sprite-locals in the palette. Or maybe have captions “Global variables:” and “Sprite-local variables:” (or maybe “For all sprites” and “For this sprite only” to match the radio button text). And probably no captions if there are no sprite variables in this sprite.

By the way, Jens reminds me that variable names aren't resolved until the script is running, so a name that represented a global variable at birth could be a sprite-local or procedure-local variable by the time it's used. That argues against putting visual scope information in variable blobs in scripts. There are good reasons why you might want to shadow a global variable in a particular sprite, and have common procedures do the right thing when used in other sprites (the var is global) and in this sprite (the var is local).

By the way, I think we have a pretty good record of taking user suggestions seriously. But I confess that we're not so interested in suggestions that seem to be based on the idea that however Java (or maybe C++) does things is The Right Way. For instance, our OOP system for sprites in 4.1 is prototype-based, not class/instance based. We think class/instance is okay for a compiled language, but in an interactive system like ours, users want to be able to play with an example of some kind of object directly, and then clone it, using the old one as the prototype for the new one. (Javascript, by the way, makes things way too complicated by having a required object called foo.prototype for every object foo. What they really mean is for foo to be a class, but they read somewhere that prototyping is cool, so they distort prototyping to look exactly like class/instance.)

We took Nathan's suggestion on how to implement a multi-branched conditional. (See the library with that name.) We've taken user suggestions about the music blocks. I'm spacing on other examples, but they do exist; I'm just old and tired.

Dale_Mahalko
New to Scratch
48 posts

Snap! user discussion

That “Run (Ring of (command)) on Sprite with Inputs” block is weird. I see that it works to send whatever command blocks you want to a sprite, but then the next question is how to get input back from those sprites.

Apparently I cannot read what the mouse cursor is touching, from a main script that is inside the stage.

Can this be made to work without touch scripts placed inside the external sprites, reporting their state back via global variables?
http://snap.berkeley.edu/snapsource/snap.html#present:Username=lhs-dmahalko&ProjectName=External%20Sprite%20Control
bharvey
Scratcher
1000+ posts

Snap! user discussion

Dale_Mahalko wrote:

but then the next question is how to get input back from those sprites.
Oh, you use CALL instead of RUN, and put a ringed reporter in the first slot.

We have library blocks TELL (for RUN) and ASK (for CALL) that hide the OF business. But it really does make sense; OF reports a script or an expression that's tied to the other sprite, and RUN or CALL evaluates it.

I don't completely understand what you're trying to do, but does CALL/ASK solve the problem?

BookOwl
Scratcher
1000+ posts

Snap! user discussion

bharvey wrote:

We can do OOP, it just doesn't use the syntax to which you're accustomed.
IMHO, object oriented design is overrated. I prefer the ML/Haskell like approach where you create lots of small immutable data types and use functions to transform them into the result you need.

who needs signatures

Powered by DjangoBB

Standard | Mobile